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(57) Abstract 



The invention comprises an electronically secured inter-processor and virtual device communications system, with an input/output 
controller board, a multi-drop bus interface to multiple devices, and a parallel interface to an industry standard single board computer. The 
invention assigns a bus address and virtual identification number to each device and controls communications between the main central 
processing unit and the devices through a Plug-n-Play protocol. 
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SECURED INTER-PROCESSOR AND VIRTUAL DEVICE 
COMMUNICATIONS SYSTEM 
FIELD OF THE INVENTION 

The present invention is directed generally to an electronically secured 
inter-processor and virtual device communication system used in gaming 
machines and is directed more particularly to an electronically secured inter- 
processor and virtual device communications system with (1) an 
Input/Output Controller Board (hereinafter referred to as "IOCB"), (2) a multi- 
drop bus interfacing one or more device modules, (3) a parallel interface to 
an industry standard main single board computer (hereinafter referred to as 
the "SBC") of the gaming machine and (4) a IOCB-to-device "Plug-N-Play 
protocol (the "Plug-N-Play Protocol"). 
BACKGROUND OF THE INVENTION 

Conventional methods of integrating a variety of components in a 
gaming machine currently require re-designing, re-wiring and re- 
programming the gaming machine as each new component is added. As 
technology advances, newer state-of-the-art devices are being offered to 
manufacturers of gaming machines that would greatly enhance the product, 
but manufacturers are inhibited, as removing and replacing the old devices 
with new devices, or simply adding the new device requires reprogramming 
the SBC and could require the re-design and/or replacement of the SBC. 

The industry standard SBC board, independent of the microprocessor 
used, has been designed using discrete components with EPROM memory 
chips containing software with an individual bus connected . to each device. 
As most of the gaming machines in the market require some sort of 
regulatory approval, modifying a previously approved product requires a re- * 
submittal to the regulatory agency with the re-submittal emphasising 
recertification of the programming of the new device in the CPU; With the 
software for each device residing in the EPROM, this requires re verification 
of the entire program. - , 

- - Especially for manufacturers with a significant installed base of 
gaming machines, retrofitting these machines with ainewer device is an ' t 
expensive proposition and a logistical nightmare. Utilising a 'Plug-N-Play' v 
concept, the Invention, through the Input/Output Controller Board (IOCB), 
logically interconnects all the devices in the gaming machine to the SBC. 
The IOCB's communications to and from each device is based on a network- 
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capable communications protocol, such as Philips' Inter-Integrated Circuit 
(I 2 C) two-wire Seriai Interface (hereinafter "PHILIPS I 2 C"). 

' As the IOCB logically interconnects the modules or potential modules 
to the SBC, die SBC and its EPROM memory chips do not have to be 
reprogrammed, resigned or replaced.' Further, as no device related software 
resides on the. SBC or its EPROMS, no new software needs to be resubmitted 
to emy^egulatdry. agency, as no new software is created; Instead each device 
in the machine incorporates an intelligent board with microprocessor (the 
"Device Board") which is programmed specifically to the functions of that 
device, thi'j3evice Board 'alsd'ctommunicates via the communications 
protocoi;'such as MtlPS I 2 C; to the IOCB in a multi-drop configuration. 
Replacing a device or adding a new device is simply a matter of connecting 
the communications interface (Clock, Data, Logic Power, System Ground) to 
the multi-drop bus interconnecting all the devices to the IOCB. 

The IOCB programming module continuously monitors the 
communications protocol interface (the PHILIPS I 2 C line) for device activity 
and relays these actions to and from the SBC: As new devices are added to 
the link, a specific registration protocol is followed which will allow the 
device to register with the IOCB. If the registering device has followed all 
the secured protocols, the specific parameters of the device (device type, 
Serial Number, etc.) are relayed to the SBC. 

The SBC has several modules programmed for all possible devices that 
may connect to the machine, such as a Coin In, Coin Out, and Bill Acceptor 
modules. Even though therdmaybe several types of these devices, the 
appropriate SBC module simply monitors for coins in, coins out and bills 
accepted. The specific hardware and protocol of each connected device is 
level converted and formatted by each Device Board to a generic format 
required by the SBC module. 

Accordingly, an object of the invention is an electronically secured 
inter-processor and virtual device communication system which allows 
devices to be added to, replaced in or changed in a gaming machine without 
any need to reprogram or redesign the SBC of the gaming "machine. 

A. further object of the invention is an electronically secured inter- 
processor and virtual device communication system which allows devices to 
be' added, replaced in, or changed in a gaining machine without a need to 
replace the SBC of the gaming machine. 
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An additional object of the invention is an electronically secured mter- 
processor and.yirtual device communication system which . allows devices to 
be added to, changed in, or replaced in a gaming machine witHput the need 
to modify the software residing in the CPU or any device so that a 
.resubmittal to an appropriate regulatory body would npt.be necessaiy. 
» Still another object of the ; inyention is an electronically ^ secured inter- 
processor and virtual device communication system r wWch cost-effectively 
allows devices to be changed in a gaming machine. I , ; rf 

Furthermore, an object of the invention is an electronically secured 
inter-processpr and virtual ( device cpmmunication.sy^tqm which allows 
devices to most efficiently beadded to, replaced in or changed in a gaming 
niachine. r . ( v - - . / , ; . ' 

An additional object of the invention is an electronically secured inter- 
processor and virtual device communication system with a.protocol which 
supports dynamic assignment,*^ device addresses. 

. Still a further object of Jhe invention is an electronically secured ihter- 
processor and virtual device communication system which provides reliable 
and secure communications among interprocessors. ^ 
SUMMARY OF THE INVENTION 

These and other objects of the invention, which shall become apparent 
hereafter, are achieved by providing an electronically secured inter-processor 
and virtual device communication system, including an IOCB connecting a 
multitude of peripheral gaming machine devices and the SBC through 
parallel interface.- In an embodiment, the IOCB provides mi interface 
between the SBC of the gaming machine and the- machine's devices and is 
connected to the SBC through a parallel interface. The IOCB uses a multi- 
drop communication bus for its connection with the devices requiring at 
least four wires, for the,clock, data, logic power, and system.grbund protocol. 
Each device contains its own CPU board programmed for the specific device. 
When power is first applied to, the gaming machine, the IOCB attempts to 
establish a link with .the SBC by placing a 'link request' transaction in the 
IOCB's transmit queue and commencing an idle state. The IOCB then 
remains in an idle state until the SBC acknowledges a physical connection. 
Once the SBC acknowledges a physical connection, the iOCB sends ; the link 
request' transaction to the SBC, preferably through the IOCB's Parallel Slave 
Port (Data) (the "PSP-Data"). When the link is established, the IOCB sends a 



WQ99/61994 



4 



PCT/AU99/00389 



framed packet to the SBC containing the Virtual ID and device registration 
commences. Independently of the SBC and the IOCB, each device's CPU 
attempts to register the device's hardware with the IOCB through the multi- 
drop bus. As ^he lOCB registers each device, the IOCB assigns an 
communications' protocol address, preferably the PHILIPS I 2 C address, to the 
device and creates a device table entry containing data uniquely identifying 
the device, such as type of device, serial number, and the communications 
protocol address As each device is registered, the SBC assigns and stores a 
virtual identification number (the "Virtual ID"). After all devices are 
registered, ,the IOCB stores information about each registered device and 
transfers any, pertinent packets received from a device to the SBC. 

In a preferred embodiment, the IOCB is the only ekterrial device 
interfacing the SBC with the gaming machine's devices such as Deck Buttons 
and Lamps, Coin In Mechanisms, Coin Out Hoppers, Bill Acceptors, 
Magnetic-Stripe Card Readers, Keypads, Progressive Display Interfaces, 
Ticket Printers, Coupon Dispensers, Hard keters and general' Security 
switches in the machine. The IOCB's physical connection to the SBC is 
preferably via a parallel interface on the SBC, preferably a PC-104 bus which 
is capable of transfer rates up to 8 million bytes per second. The data 
transfer between the IOCB and SBC is interrupt-driven and controlled by an 
8-bit register. 

The IOCB interfaces the listed devices through a Multi-Drop 
communication scheme using a network-capable communications protocol, 
such as RS-485, USB, current loop, or preferably Philips Corporation's two- 
wire Inter-Integrated Circuit (I 2 C) serial interface and corresponding 
communications protocol ("hereinafter "I 2 C protocol"); which enables speeds 
up to 400 kbps. 

The communications protocol, preferably the I^C protocol, ensures 
reliable transmission and reception of data. When transmitting data, only 
one apparatus, preferably the IOCB, is the 'master' which initiates transfer on 
the bus and generates the clock signals to permit that transfer,' while the 
other device(s) acts as the 'slaves*. 

The Philips communication protocol ("I 2 C Protocol") operates on top of 
Philip's published industry standard f C protocol. Additional information on 
the PHILIPS I 2 C specification can be obtained from the document "The fC 
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bus and how to use if, #939839340011," available 'fem'^e pkilip^ J " r J 
Corporation. _ , 

The communications protocol, preferably the I C protocol, constitutes 
the physical layer for the invention's IOCB to Device Tlug-N-ttay protocol, 
5 whichjs a packet-driven securitized protocol. /° 1 ' J : * ai : " 
The preferably I 2 C framed Tlug-N-Play' protoi:^ 
assignment of I 2 C addresses, facilitates" reliable communications between I 2 C 
devices and the IOCB and provides a secured lirik'for ihter-prbcessor 
communications. 

10 A multi-wire Multi-Drop bus, preferably, a four-wire multi-drop bus 

(Clock, Data, Logic Power, System Ground), interconnects all devices 
throughout the. machine to the IOCB. Each device is equipped with a 
firmware-based CPU board which is programmed to the specific parameters 
and purpose of each.device. Each device's CPU board is capable of"" 

15 communicating with the communications protocol, preferably the I ? C 
protocol, r ' '[ 

Messages are routed to and from the IOCB to the devices using a 
communications protocol framed packet, preferably an I C framed packet 
. comprised of an I 2 C address, header, body and footer, as specified below. 

20 To prevent statistical breakdown of the CRC-16, packets will be limited 

to a maximum of 255 bytes inclusive of the I 2 C Address and Footer. Message 
bodies larger than 248 bytes must be broken up into multiple 
communications protocol framed packets, preferably f C framing packets. 

When power is first applied to the gaining machine, the IOCB attempts 

25 to. establish a link with the SBC by placing a 'link-request' transaction in the 
IOCB transmit queue, which commences an idle state! The IOCB remains in 
this idle state until the SBC acknowledges a physical connection' Upon 
receiving acknowledgment of the physical connection, the IOCB sends this 
link request transaction to the SBC via preferably the Parallel Slave Port (PSP 

30 Data] of the IOCB.through a PSP-framed packet containing the Virtual ID of 
the device. Once the link is established, device registration begins. Neither 
the IOCB nor the SBC has knowledge of the devices" integrated in'the " 
machine. Each device's CPU will attempt to 'register' its specific hardware 
with the IOCB by communication through the communications protocol 

35 multi-drop bus, preferably a I 2 C Multi-Drop bus. As each device 4s registered 
by the IOCB, the IOCB dynamically assigns a communications protocol 
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address, (range 9-76h),. preferably an I 2 Q address, to the device and enters the 
device information into a device table which stores the device's specific data 
,(type of device^ serial number, etc.). As long as power is applied to this 
device, a device responds to IOCB requests using this communications 
protocol address, such as an I 2 C address. The IOCB also assigns Virtual ID 
(Circuit Number) to the device referencing the device to the SBC. The SBC 
uses ; this Virtual ID to invoke a software driver referencing this device type 
regardless of its communications protocol, preferably I 2 C, address. The 
Virtual. ID remains assigned to the device and, should the device lose power, 
upon re-registering, the device may receive a different communications 
protocol, preferably I 2 C, address but will maintain the same Virtual ID. This 
process repeats until all devices have been registered. 

As each new device is dynamically registered, a table entry in the 
IOCB's device table is created for that device. As the IOCB is contiguously 
polling these registered devices, the IOCB will detect removal of a device and 
will send notification to the SBC. 

After device registration, utilising a prioritized polling scheme, the 
IOCB will query each registered device for status. The IOCB either receives a 
'no activity' packet or a packet containing pertinent data for that device. If 
required, the IOCB transfers a valid packet to the SBC via preferably the PSP- 
Data port. 

If a registered device fails to respond to its poll after a fixed nuiiiber of 
retries, the IOCB declares the device 'inactive* by sending an appropriate PSP 
framed transaction to the SBC. 

The IOCB communicates with the SBC via a parallel port connected to 
a PC-104 bus on a SBC. The interrupt-driven data transfer is controlled by a 
shared 8-bit register which is used as handshaking flags for flow control. 

The communications protocol bus is a multi-wire communications 
interface, preferably a I 2 C bus with a two-wire serial interface developed by 
the Philips, Corporation which enables speeds up to 400 kbps. 

The IOCB will be interrupted by the FSP-Data if the SBC initiates any 
PSP framed transactions. If the SBC initiates a transaction, the IOCB will 
wrap the PSP framed characters with communications protocol framing 
characters, such as I 2 C framing characters, sending this data to the 
appropriate device at that communications protocol address. 
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! in any setting, the IOCB's sole resporisibiiitjfis to Sirectfsettired ( data 
transactions to and from the SBC and to andlrom th J e ganiihg'niachirie's - 
devices. The IOCB does not initiate or control ahy ^ 'functions iif the gaming 
machine. . .. . r , . /%r - ^ . 
BRIEF DESCRIPTION OF THE DRAWINGS ^ ^ ; ^ ^ 1 ' ^ 1 

; The ^invention would be better understood froth the following Detailed 
Description of the Preferred and Alternate Embodiments;' with reference to 
the accompanying drawings, of which: J . f " v ' 

Figure 1 is one embodiment of the inventibn^'^ SBC of the 

gaming machine connected to the iOCB and confab Cted :: t'# 's'e Ven^deVices 
through device boards in a jnulii-drop bias cohfigufatiori'. J " '< * } " J " 

Figure 2 is, an embodimeht'of the invention, showing the preferred PC- 
4Q4jouS;Of,the SBC pnnected through a preferred parallel interface by an 8- 
bit bi-directional bus to two parallel slave ports (PSP-Daita and Control, and 
the 8-bit register) of the IOCB. / J 

Figure .3 is a preferred embodiment of the invention, showing the IOCB 
connected in a multidrop configuration with four wires to five devices. 

Figure .4 is a flow chart showing the transmission of data from the SBC 
to the devices through the IOCB. ' ' ' - 

Figure 5 is a flowchart showing the transmission of data from the 
. devices to the SBC through the IOCB. 

Figure 6 is a flowchart depicting the four-level security of the 
invention, which ensures the validity of data transfers, and" ; 

Figure 7 is a flowchart depicting the registration of devices by the 

IOCB. . " ... ... . [ 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Referring to the drawings, wherein like numerals reflect like elements 

throughout the several views, Figure 1 depicts the SBC (generally 1 ) of the 

gaming machine, as.connected to the Input/Output Con^olldr Board ("IOCB") 

(generally 200). The IOCB 200 is connected in a multi-drop bus 

configuration 250 to the devices (3A, 3B, 3d, 3D,' 3E, 3Fi 3G), eath device 

with its own microprocessor inclusive board (respectively, 4A, 4B; 4C; 4D, 

4E, 4F, 4G). The devices depicted are a coin comparator 3A, a bill Validator 

coupon 3B, a coin out hopper 3C, a magnetic card reader 3D; a coUpoh- 

dispenser 3E^ a progressive interface 3F, and a deck buttonsAamps' 3G. /Each 

device (3A through 3G) has its own board (4A through 4G) (the "Device 
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Boards 1 ') and is virtually connected to the SBC I and to the other devices 
through the multi-drop bus configuration 250. 
Single Board Computer (SBC): 
• , . The SBC 1 is capable of digital storage, contains a microprocessor, 
5 preferably a Pentii^m II, and preferably contains sound and video capability, 
wave file capability, networking capability, and modem connections. L 
Input/Output Controller Board (IOCB): 

The IOCB 200 is a Microprocessor based electronic board featuring a 
microprocessor, preferably a PIC 17C756, preferably on-board Random * 
10 Access Memory (RAM),, preferably Non-Volatile RAM/preferably 

timer/counters, preferably Captufe/Compare/PWM modules, preferably two 8- ^ 
bit parallel ports (Parallel Slave Port (PSP) Data 201, PSP Control 202), . 
"■" preferably'qn'e Serial Communications Interface, preferably two-wue Inter- 
1 Integrated Circuit (I 2 C) bus 203, preferably internal/external Interrupt 
15 sources, preferably a Watchdog Timer, preferably a Brownout detection and 
preferably Programmable code-protection. The IOCB 200 has the ability to 
set up and communicate in the communications protocol standard, to 
communication with at least one device, and to perform distributed 
processing. 

20 Device Microprocessor Board Hardware : 

Attached to each device 3A through 3G in the gaming machine is a 
Microprocessor based electronic CPU board (the "Device Board.") 4A through 
4G. Each board is specifically designed and programmed to interface with 
the specific function of its associated device.' The devices are connected to 

25 the IOCB 200 in a multi-drop configuration 250. Each board is capable of 

communicating in a communications protocol, preferably an Inter-Integrated 
Circuit (I 2 C) communications protocol, and contains a microprocessor, 
preferably a PIC 16C67. Integrated components of the board (size of RAM, 
high current output drivers, etc.) are application specific. Each board 4A, 4B, 

30 4C, 4D, 4E, 4F, 4G contains a memory component, preferably a 64-bit 

serialised memory' component, which is used as another security check in the 
design. The unique serial number of each component of each Device Board 
is installed into the board at time of production and provides a unique 
identification number for each board (the "Board"). The Board ID is used in 

35 the packet transmissions to and from the IOCB 200 as another signature 
verification in the calculation of the CRC-16.* 
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Figure 2 depicts the preferred PC-1Q4 port 100 of the SBC 1 connected 
by preferably an 8 bit bi-directional bus to preferably the 'iqCFs'PSP-Data 
201,and PSP-Control.202 port and to the IOCB's 8-bit regisfer^' fi - 
.Communication to and from the SBC 1 is accompHsned''tnr6trgn" the IOCB's 8- 
5 bit PSP Data and PSP-Control port 201*202 andj^ep^s^-104-t^ ; iob 
and the bi-directional interrupt driven, data transfers utilise a'share'd 8-bit 
register, 205 which regulates, data direction and flow "control. ^ Depending on 
its specific task, the IOCB 200 will set and reset'the handsKalang control bits, 
with the SBC 1 to monitor these status bits. 
10 .. • ■■•••+ .. . Each,bit of. the 8. bi^register 205 preferably, is p^opulatied as follows: 



bit . ■ 


. ;, - .7 


r. .•>. . 6 


5 


■ 4 


3 


2 


: 1 


' : ' ; ' :: 0 




RTR . 


l -RA i .... 


■ RTT, 


TA 


CONNECT 


d7 


ZERO 

i 7 


RESET 



• -Bit 7 - Ready To Receive (RTR) 202A preferably indicates, if se'C that the 

IOCB 200 is ready to receive a ^ata byte. If the SBC 1 has a character to 
15 send, it reads this statusbit and if set, will send the character. If reset, a 

time-out interval is initiated and if it expires, the SBC will report an error 
which locks up the game. ^ ^ ^ . . 

• Bit 6, - Receive Aborted (RA) 202B preferably indicates, if set, that the 

* IOCB has detected a communication error while receiving data. The SBC 
20 ;] 1 also monitors bit 6 prior to. sending a character, and if Bit 6 is set, the 
SBC 1, will abort the balance of the transmission and retry again. 

• Bit 5 - Ready. To Transmit (RTT) 2 02 C preferably indicates, if set, that the 

. JOCB 200 has data-to send.. When set, this bit asserts Interrupt Request 11 
(IRQ1 1) on the SBC,1. Once the interrupt has been serviced and the 
25 v character has been read, the IOCB 200 notifies its PSP hardware 201, 202 
* . and resets this. bit. The IOCB 200 then generates a Transmit Data Register 
Empty interrupt signalling that another character may be sent. . 

• Bit 4 - Transmit Abort. (TA) 202D preferably indicates, if set, that the IOCB 
200-has detected an internal transmission error while transmitting a packet 

30 Jo the SBC ,1 and that no more data will be sent. If the SBC 1 detects that 

- this bit is set, itwill clear any .previous characters received and abort the 
; receive process. . 

• Bit 3 - Busy 202E preferably indicates, Jf set, that the IOCB 200 i? ; busy 
processing a critical application and prevents the SBC 1 from an erroneous 
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.., timeout on a data transfer., TheJOCB 200 sets this bit/upon entering a 
critical application, resetting it upon completion. The SBC 1 will initiate a 
, longer timerout interval, but upon expiration, will report an error locking 
■ up the, game. 

• Bit2>0 202F This bit is reserved for future use. 

• Bit 1 - Connect 202G preferably indicates, if set, that the handshaking flags 
•of this rfegis teii should be ignored. The IOCB 200 sets this bit to the vtflue 

a > 1 (indicating highr impedance) if the IOCB 200 and SBC 1 are 

disconneqted/,as,tlie ;i 1ji-state inputs of the PSP hardware will be high, The 
IOCB 2QG ,sets th|s bit to the .value 0 if the IOCB 200 and SBC 1 are 
connected These tri-state inputs (high, low, high-impedance) prevent 
interference between multiple devices attempting to access the line and 
allow the IOCB 200 to act as a traffic controller. The IOCB 200 always 
resets the bit to prevent erroneous actions based on bit levels being set. 

• , Bit 0 - Reset 202H preferably indicates to the SBC 1, if set, that the IOCB 

200 has been up or reset, alerting the SBC 1 to set the 'state* of the gaming 
devices in the machine. That bit is reset each time initial communications 
are established between the IOCB 200 and the SBC 1. 

Figure 3 depicts the interconnections among the IOCB 200 and five 
devices 3 in the preferred I 2 C multi-drop configuration 250. The IOCB's I 2 C 
port 203 is connected to each Device Board 4 through preferably a four-wire 
multi-drop bus 250, The preferred I 2 C capable multi-drop bus 203 has 
; preferably four wires (clock 251, data 252, Logic Power 253 and System 
Ground 254) which are distributed through the machine, providing the 
Device Boards 4 with a means to utilise the clock, data, power and a ground 
of the IOCB 200. Each device 3 is equipped with a Microprocessor based 
electronic circuit board 4 (the "Device Board") which is specifically designed 
to interface with the device's input or output signals depending on the 
device. The Device Boards 4 are capable of communicating using network- 
* capable communications protocols, preferably Inter-Integrated Circuit (I 2 C) 
protocols, enabling interconnection among the devices 3. In the preferred fC 
multi-drop bus 250, clock 251, data 252, Logic Power 253 and System Ground 
254 are distributed in each device providing a clock, data transmission, 
power and ground to the Device Boards 4. A Device Board 4 can be attached 
to more than one Device 3. In that event, more than one device will have a 
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single communications protocol address 1 (preferably air f G address); but each 
device will have a unique Virtual ID. i ! ; 1 J 1 r ' - f A ■ ■•* t,l /' : 1 ' 

Figure 4 depicts data transfers of SBC-initiated frarisriiisiions between 
the devices 3 and the SBC 1 through the IOCB 200. Data tr&nsfers^between 
5 the IOCB 200 and the SBC 1 are based on'a PSP framed' pkfcket SOfcwith the 
[ preferably following protocol: • f ^ <->- rr ^-' ~ ? h \ 

[Virtual IJD] [size] [sequence #][Cbmmand][:.bbdy>:][ETX][CRG-16] 

• Virtual ID 500A: this byte preferably contains .a circuit 1 number or 
' J reference numbier by th6 SBC l deteririineis ; whieh : device-specific 

10 software driver is usdd to interpret i to 

V device 3 or to generate the pWfticiilardata sent to lie device 3. 

# 'Size 5o6B: , this byie preferably contains the' character lengthof the 
P3P framed packet from Virtiial ID 500A to the CRC-16 500G 



inclusive. 



15 # Sequence 500C: this byte' preferably contains the message sender's 

next sequential number. The 'message receiver-maintains an 
expected sequential reception number corresponding to the message 
sender's Virtual ID. Thik sequence number is initiated to a 0 value 
and is incremented by 1 for each successful' transmission, wrapping 

20 at the value of 255 back' to a valutis of 1. : The value of 0 is only used 

on initial setup; and if the value is 0, the message receiver resets its 
expected sequence number. The sequence number provides'' 
additional security to ensure that all transmissions are received (see 
Figure 6). If the message receiver has accepted the valid transaction 

25 (all packet criteria has been" satisfied), this constitutes a successful 

transmission and the message receiver responds ; to the' message 
sender by transmitting an acknowledge (ACK)packet Which will 
cause the message sender and receiver to increment -their sequence 
numbers. ' : ■ ' *• ' ■ ' : %; 

30, ' • Command 5000: this byte preferably 1 informs : the-message receiver 
what to do with the (if any) in the body of the' message. 1 For 
example, if this bytes contains "ACK", this acknowledges the ■- 
* message sender's last received packet and contain 0 bytes in the 
body of the message. Similarly! the IOCB 200 sends a Link Request 

35 * command (with 0 bytes)to the SBC 1 on power-up; which requests a 

communication link. In an additional example, a Bill Acceptor 
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f \ transaction with, a command of'B' signifies that the Bill 

Denomination is in the message body and contains four bytes in the 
.. body of the message. "ACK" has the hexadecimal value of 06, 
f , . indicating, a positive acknowledgment. "NAK" has the hexadecimal 
5 , . . yahie o£l5> indicating a negative ac knowledgment. 

^ r •• - t Bp4y 5p0E: this byte preferably contains a variable number of bytes 

, ; w from p to 248, contains pertinent data regarding the transaction. For 

• , . . ' - example, this field may contain the denomination of the bill 
... , , ; ac^pted^th^qqin denomination, or the Player's Account Number 
10 pipqessed by > the Magnetic Card Reader. The actual specific data 

contained are determined by ? the Virtual ID involved. 
• ETX 500F: this End of Transmission (ETX) byte is preferably used 
... . for packet,. ETX has a hexadecimal value of 04, signalling End of 
, the Transmission. 
15 ^ > • CRC-16 500G: this two-byte field preferably is a 16-bit Cyclic 

Redundancy Check (CRC) value, used for packet validation and 
: security. The CRC-16 value is generated using a 16-bit reverse 
polynomial-based algorithm performed on each transmitted/received 
: r ,byte. This 16-bit value is initially set to 0 and each byte of each 
20 Device Board 4 and the device type byte (Coin Mechanism, Bill 

Acceptor, etc.) is cyclic redundancy checked (CRC'd). The resultant 
16-bit value, called the 'seed', is used as the initial value prior to 
applying the CRC algorithm to each byte in the packet. A CRC value 
is generated for each packet and includes the entire packet, from 
25 , Virtual ID to ETX inclusive. A packet's CRC value is compared to 

the device's 3 seed and should be equivalent if the packet has been 
. successfully transmitted. The CRC-16 'seeding' is applied to all 
transactions except the 'R'egister Command., which is used when a 
device 3 is being registered for inclusion in the device table (see 
30 Figure 7). With the Register command, the receiver does not have 

any knowledge of the Board ID or the type of device registering in 
the communication packet, the seed is assumed to be 0. In the 
, . examples., the CRC-16 value of 'OxCCCC is used for reference only. 
The actual 16-bit value would vaiy depending on the data bytes in 
35 ; the packet. 
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Communication packets transferred 'between ^\he SBG ^aftid the IOCB 
200 (PSP framed' packets 500) preferably have a 1 Virtiikl ID SOOA-embedded in 
the packet which is used to steer the transaction to the'appropfidte software 
driver of the appropriate device. Communication padkeis^traji^ferred 
between the IOQB 200 and the device 3 (preferably I 2 C framed packets 520) 
, preferably use an I 2 C address 520A to steer the transactidfl; W^IOCB 200 
directs transactions both between the IOCB 200 and the 3B'C 1 ahd between 
the IOCB 200 and the devices 3V Due to 'its dual furidtion'/ 'the IOCB 200 must 
wrap 524^ 525,526; 527 the SBC-generated PSP packet 500 vvith y preferably I 2 C 
framing 520 prior to sending 528 the packet-to a (iyviceP^tiKe'wise, it must 
unwrap (Figure 5, 616) ihe preferably I 2 C 5 friime 5 
generated PSP packet 500 prior to sending the packet 1 to ttie SBC 1. 

feach Device Board 4 may have more than one physical device attached 
to it. For example, a Device Board 4 may be attached to two? hoppers, one to 
dispense coins /the other to dispense tokens. As a Device Board' 4 'has only 
one communications protocol address, preferably the I C address 520A, but 
two Virtual IDs 500A, the IOCB 200 checks 552 its device table 552 for two 
table entries with the 1 same I 2 C address 520A. Utilising bbth the PSP and 
the I 2 C framed protocols, the IOCB 200 directs 528 both SBC 1 generated 
commands (in our example, 'C & T) to the same fC J address 5 20 A. The 
Device 3 at that I 2 C address 520A will unwrap 5'44 the I 2 C framing bytes and 
act on 546, 548 the PSP Virtual ID's Commandite 500D and message body 

500E. ' ' \ ■ 

The following example further illustrates the process by which the 
IOCB 200 wraps a PSP framed packet 500/ ; The SBC 1 wants to' turn on Deck 
Lamp #4 with the device's Virtual ID of 126, the sender's next sequential 
transmission number of 56, and the command byte of 'L\ Using' the following 
PSP packet format 500 and values: ...-•<.'-..- * . « 

[Virtual ID] [size] [sequence #] [Cbmniand] [ body ] : [Ef X] [CRC-16] 
^ [126] [8] [56] [ L ] " 4 [0x04]* [ETX] [OxCCCC] 

The t*SP packet 500 will'contain the above listed data. Assuming there 
are hp communication errors and the packet criteria is acceptable (see Figure 
6), the IOCB 200 references its device table 554, finds this Virtual ID value 
126 at I 2 C address value 32. By these values, the IOCB 200 determines 551 
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that the data packet 500 initiated from the SBC 1, determines 553 that the 
received data packet is not intended for the IOCB 200 and thereby ignores 
555 the .sequencernumber 500C, the Command 500D and the body 500E of 
this packet.,. The! IOCB 200 uses the size byte 500B only to count down the 
received bytes, i.e. mark the end of the packet 557. 

The:IOCB 200 then wraps this packet with its own I Z C frame. The 
IOCB 200 first creates 525 the. message body 520 E of an I2C packet 520 from 
the PSP packet 500;. The IOCB 200 assigns the value of "M" 526 to the 
Command.byte.52QD in the I 2 C packet 520 signifying that the SBC 1 
originated ^transaction. The IOCB 200 then assigns 527 the next available 
sequential transmission number from the IOCB 200 to the sequence number 
520C for this I 2 C address 5 20A. .The I 2 C packet 520 is assigned the I 2 C 
address. 520A of 32.(524). In the ^example, the I 2 C packet is populated as 
follows: 

[I 2 C Address] [size] [sequence*] [Command] [...body...] [ETX] [CRC-16] 
[32].. [15] [143] [M] [PSPpkf] [ETX] [OxCCCC] 

> The IOCB 200 then sends 528 the I 2 C packet 520 to the device 3. 
Assuming there are no communication errors and the packet criteria is 
acceptable 536, 538, the device 3 sends an I 2 C framed packet 520 to the IOCB 
200 acknowledging JACK) its transmission 532. Upon receiving the 
acknowledgment 560, the IOCB 200 creates and sends560 a PSP-framed 
packet 500 to the SBC 1 .acknowledging the Virtual ID has accepted its 

transaction. .... 

If the I 2 C Command byte 520D of 'M indicates the SBC 1 originated 
this transaction 542, as opposed to the IOCB 200, the I 2 C body 500F contains 
the PSP packet 500 sent by the SBC 1. The device 3 at this I 2 C address 
unwraps the I 2 C framing bytes 544, reads 546 the PSP framed packet 
Command ('L' in our example) and acts on 548 the Command by turning on 
Lamp #4. 

... Figure 5 depicts data transfers for device-initiated transmissions among 
the devices 3 and the SBC 1 through the IOCB 200. The communications 
protocol framed packet, preferably the I 2 C framed packet 520, is transferred 
between the IOCB 200 and the device 3. Each preferred I 2 C framed packet is 
comprised of the following parameters. 
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• I 2 C Address 520A - Range 9 to76h; } :;f ^ * • - tcrr b r 1' I: 

- 0 reserved ; fbr Broadciasf Address/ ' ^ ■/ f ■ . . 
" " - 1-7 reserved for I 2 C implementation;"'* 

' " - 8 reserved for the IOGB Addreiss^'i:-^ ■-.< !j 
5 ^ - 77h reserved for unregistered devices; 

• ■* Header 520B, 520C, 520D - Packet Size, Sequence 'NumBefilCoifiniand 

(each one byte). '■ , ; ? .- ; .-v.::i ;irf!. ! *>0S * 
. The "ACK" value for Cbmmand has a hexadecimabVMuetof 06,; , ^ 
indicating a successfuftransmission, and* the l 'iSfAK M ^ value for . 
10 Command has a hexadecimal value of 15, ifcd^^^ 

... transmission. ' r ' ' • - !: --- ; - -"'^ ^- v; 'iV^-n 

• BpdyMOE " ' - Up to 248 bytes of binaiy data. -* . v .; 

• Footer 520Fi 520G - ETX, CRC-16 (2 byte Cyclic Redundancy 

Check). ^ 
15 -;, > - ... For example, a Device Board 4 has three devices 3 attached to it: Deck , 
buttons, Deck lamps, afid a Coin-in Mechanism. Each of these devices,3 is 
assigned its own Virtual ID SOOA'but the Device Board ! 4 only possesses one 
I 2 C address 520A. In the example, the Coin-in Mechanism's Virtual ID is 41, 
the Deck button's Virtual ID ii 14, and the Deck lamp's Virtual* ED is 126. The 
20 • I 2 C address 520Ais 39 t ■*■"" 

Assume a coin has been inserted in the gaming machine. The Device 
Board 4.detects this Coin-in action and, using the CoiMn Mechanism's 
Virtual ID 500A of 41, sequence number 500C of 214, : Command 500D of T, 
and the coin value 500E' of 25 (hex 19); the device 3*gerierates 572, 574; 576, 
25 578 the following PSP packet 500 with the following values: 

[Virtual ID] [size] [sequence #j [Command] [...body,-..] [ETX]. [CRC7I6] 
[41] ; [9] '[214] ' [,I,] - [0x0019] i- [ETX] C [OxCCCC] 

30 The PSP packet 500 is intended for the SBC 1, and, accordingly, the 

PSP Packet 500 must be encapsulated within an I 2 C packet for' delivery to the 
IQCB 200 to be delivered to the SBC 1. The PSP packet 500 becomes the 
body 520E of the I 2 C packet 520 (586), for which the additiorial following 
value are assigned 586, 588, 590, 592, 594, 596 to the I 2 C packet 520: the 

35 IOCB's hard-coded fC address 520A of 8, a sequence number 5 20 C of 79, an 
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I 2 C Command 520D of D r signifying "Device" originated, creating the 
following I 2 G packet 520: 

[I 2 p Address] [size], [sequence*] [Command] [...body...] [ETX] [CRC-16] 
, [8] "^.^[16L ;, [79] [D] [PSPpkt] [ETX] [OxCCCC] 

TJhe device 3 waits 610 until the next poll received from the IOCB 200 
and then sends 612 the I 2 C packet 520 to the IOCB 200. Once the IOCB 200 
receives the packet, it checks the "command" byte 520D of the I C packet 
and, if'!Q : Q^ 614, the IOCB 200 strips 616 the 

I 2 C framing characters. The IOCB 200 then sends 618 the PSP packet 500, 
extracted from the body 520E pf the I 2 C packet 520, to the SBC 1 as: 

[VirtuaLlD] [size] [sequence #] [Command] [...body...] [ETX] [CRC-16] 
[41] , . . . [9] [214] ' [I] [0x0019] ' [ETX] [OxCCCC] 

This PSP packet 500 is the original packet generated by the Device 3 
(see 572 r 574, 576, 578, 580,582, 584). The SBC 1, upon receiving a coih-in 
transaction, checks if there are any communication errors 6i22 and if the 
packet criteria is acceptable 620 (see Figure 6). If the packet is okay, the SBC 
1 takes appropriate internal action. If the packet has been validly 
transmitted, the SBC 1 also sends an ACK transaction to the Device 3. First, 
the SBC 1, generates 624 the following PSP framed packet 500, assigning 
"Command" 520D the value of "ACK" 626, assigning other values 528, and 
sends 633 it to the IOCB 200 as: 

[Virtual ID] [size] [sequence #] [Command] [...body...] [ETX] [CRC-16] 
[41] . [7] [214] \ [ACK] [0 bytes] [ETX] [OxCCCC] 

" Once again, the IOCB 200 encapsulates 634 this PSP packet 500 with 
its I 2 C framing characters, looks, up the I 2 C address 520A associated with the 
Virtual ID 638, assigns, the I 2 C address 640, assigns the value of "M" to 
"Command" 520D, creating the following I 2 C packet 520. The IOCB 200 then 
sends this.I 2 C packet 520 to the I 2 C address 520A found in its device table for 
this Virtual ID 500A: 
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[I 2 C Address] [size] [sequence #] [C6mma£df ^iiody'Hr {®f fCRG' : 16] 
[39] [14] [79] ['M'] [PSP j pktf ^[EtX] -[OxCCCC] 

Once the Device Board 4 detects the transmission^ 
that it was sent from theSBC 1 646, the Device Board 4 at the I 2 C address 
520A strips 64^ the fC framing characters and decodes 650 the PSP packet 
500 embedded in the body 520E the I 2 C packet 520. Tjt&'&CK Command 
confirms 652 to the Device 3 that the transaction was acdepted'by the SBC 1. 

If appropriate, the SBC 1 generates another transaction 621 to be sent 
to the Device 3 responsible for updating the hard mete^ with this 

coin-in transaction, / ^ J,!f ' . .. 

Figure 6 depicts the preferred security devices of the' invention which 
ensure the validity of the data transmissions. Each time a device 3 or the 
..SBCl seiids ^ transmission, upon receipt 670 ofthe packet, the' receiving 
module (the Receiver) checks the I 2 C packet 520 received to ensure validity 
of the received packet. First, the Receiver counts the number of characters 
received 672 and compares 674 this value to the "size" field of the'received 
packet. If the packet passes this test, the Receiver then checiks 676 if the 
"sequence number" of the received packet equals the receiver's next expected 
sequence number. If the packet passes this test, the Receiver checks if the 
ETX code is detected 678 at the correct index in the' packet. Lastly, the ; 
Receiver calculates 680 the CRC-16 value of the received packet and checks 
682 if the 16-bit CRC value received is equal to' the calculated 11 16-bit CRC. If 
any of these tests fails, this indicates a communication failure and the 
Receiver creates a NAK packet 684, assigning "Command" a' value of "NAK" 
686, assigning. the other values 688, and wraps 690 the PSP packet to notify 
the sender that the transmission failed. Upon receipt df the NAK packet, the 
sender reconstructs the packet and sends it again. If the receiver detects 698 
more than three consecutive attempts which result in failure, the appropriate 
, steps of error notification 700 are taken* " 

Should a transmitted packet fail any validation check; the receiver will 
send a Negative Acknowledge (NAK) packet 684, 686 ; , 688 to the sender 
indicating an error. The sender will retry up to three times 698 before 
declaring a communication failure 700 causing the sender to re-enter the 
initialisation state 702 and attempt to re-establish a 'communication link (see 
Figure 6). 
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Figure 7 depicts. the preferred device registration by the IOCB 200 of 

.each device, 'Upon power up 710 or reset 702^ the IOCB 200 assigns 712 the 
same default physical .fC address 520A (77h) to each device 3. If registration 
of the device is not necessary, the IOCB 200 allocates 705 bus time for each 
device .3 to register. The IOCB 200 then dynamically assigns an I 2 C address 

i707 whickls, clocked out to the responding slave device. The IOCB 200 sets 
up 709 a table 554 corresponding to this address and populates 709 the table 
with, the data it has received from this slave device. A Virtual ID 711 is 

. assigned^ j;o this device 3 c which the SBC 1 will use to invoke a software driver 
pertaining to this device 3. The IOCB 200 creates 713 a PSP packet 500 
(Virtual IP, a 'R'egister Command, and the device particulars 715, 717)' and 
sends 719 the PSP Packet 500 to the SBC 1. the SBC 1 checks 729 if this 
device is on file 727, creates an ACKnowledging PSP Packet 733 with the 
value of "ACK" for the "Command" 735, checks if the device 3 needs 
configuration 736, adds configuration parameters to the "Body" of the packet 
738, and sends 743 a Register ACKnowledge command to the IOCB 200 
confirming this device is valid and commits the tabled entry as valid 737. 
Upon receipt of the acknowledgment 745, the IOCB 200 adds 747 this f C 
address 520A to its polling list 554. If this particular device 3 needs 
configuring 736, the SBC 1 embeds 738 the configuration parameters into the 
message bqdy 500E of the Register ACKnowledge packet sent to the IOCB. 
TheJOCB 200 resends 755 these parameters in the I 2 C packet sent to the 
device 3, : 

If the SBC 1 has no information on this device 731, or this device 3 is 
not allowed in this machine 731, a Register NAK command is created 739, 
741, and sent 743 to the IOCB 200 signifying registration denial of this 
device. Upon receiving a "NAK" packet 749, the IOCB 200 re-seniis 755 the 
Register NAK cqmmand to the device and removes 751 the device's fC 
address 5 20 A in the table list of devices. The Device Board 4 re-initialises 
702, re-configures its address as 77h 712, and attempts to register 705. If 
after three attempts to register has failed 740 , the SBC 1 displays an error 
message 742. , 

On initial power-up (Figure 7, 702, 710) or reset, each Device Board 4 
is programmed as default I 2 C address 77h (see Figure 7) and, upon successful 
registration, the device's I 2 C address is added to the poll list 747. The IOCB 
200, periodically polls I 2 C address 77h for any response by following I 2 C 
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standard protocols. The protocol mandates ^ device 
other than the IOCB 200 is asserting a cfeck 771. jf noCthe idCB 200 sets 
the clock 773, raises the clock line 777, and, with itie'data ^ Kn§'252 high, 
lowers 775 the clock line 251 (start condition) thereby"ale&^^ 
3 r on the bus (Slaves), that the IOCB 200 (Master) is sending attaddress'byte. 
During registration, the IOCB^ 200 creates 783, 785, 787 ^tfserids l 79i^hl 2 C 
packetonto the data line. This packet has the address 77h " l d6ckea ( but n on 
the data line, i.e!, the first seven bits of the I 2 C address have^a value 1 of 77h 
and the eighth bit signifies either the IOCB's intent thread; a' b'yld from this 
address or s write a byte to this address. " °" 

; The IOCB 200 expects, an Ackiiowledige on ! the d£ta line' 719 r pow ' 
condition), from a device 3 at this address . The Master will provide 8 3 i the 
ninth clock for the expected ACK condition. Any devices 3 Which do not 
have I 2 C address 77h ignore 853 this prompt condition 791, 793. If a device 
or,devices 3 are at this address 795 (there may be several devices with the 
default value 77h on initial power-up), the device 3 asserts 797, 801 the data 
line low at the appropriate time to respond to the IOCB 200. ' If the 1 poll ; is 
intended for device registration (it is on initial poll), the Master sets the Read 
flag 785, 787 intending to read the responding device's registering data 1 . 5 

The I 2 C protocol mandates a stop condition 833 (a terminating f 
condition for 2 each I C transmission) which the Master (IOCB 200^br SBC 1) 
will provide. Under I 2 C mode, the Master of the'l 2 C line always provides the 
clock signal 773, even if a Read condition has been established and thus will 
read 829 the data as it provides the clock 773 by which the Slave sends the 
data. . 

If multiple devices respond 803 to the IOCB's 77h address byte; btis 
arbitration will come into play. As the IOCB provides each clock pulse 773, 
the devices will assert 811 their particular data bit dnto'the data line, but 
each device will first sample 807, 809 the data line to ensure its level is its 
intended level. If the level is not at the intended level, the particular device 
resets its I 2 C commitment 813 753, and backs out of additional involvement 
.813 until it receives 815 the next address byte from the IOCB 200. "As 
, arbitration may continue . for several bytes, the surviving device 3 will have 
finally completed its registration packet to the. IOCB 200. 
- .- . The IOCB maintains the device table 554 in preferably ltd 'Mowing 
format: 
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• Address - - Dynamically assigned I 2 C address. 

• DeviceType , „ - Type of device (i.e., Coin mech., Bill acceptor, ). 

• Sub-Type. .-. , r.Specific Make or Model. 

• ; - Serial. #> v v !•- V nic l ue Board Identification Number (Board ID). 

• , Status c;( . _ m- ^-Last reported status. • 

• Priority,_ r.?olling priority. . 

• Virtual, ID , -..SBC's end to end reference #. 

. . „ : As the IOCB 200 is continuously polling, the following example will 
detail a, typical po]]. transaction to the device at f C address 39. The poll 
Command^ izpp^ueiy will have 0 bytes in the message body. ' The IOCB's 
next sequential tiansrmssipn number 520C is 79 (the device 3 at 1 this fC 
520A address will be expecting this sequence number to be 79). The IOCB's 
I 2 C address 5 20 A is hardcoded at 8. 

[I^C Address] [size] [sequenced] [Command] [body], [EXT] [CRC-16] 
■ [39] 1 [7] . [79] ['Q'] (O bytes] [EXT] [OxCCCC] 

The IOCB 200, as Master of the I 2 C bus, will clock out these data bytes 
to the Device.Board 4 at this I 2 C address 520A'. The Write flag is set 789 in 
the packet's address byte 520A indicating the IOCB 200 is sending data. The 
device 3 ACKnowledges each byte by. asserting 799, 801 the data line at the 
ACK clock bit time frame. When the IOCB 200 has sent all bytes 819, the 
Read flag is set 821 in the address byte, and the IOCB 200 re-sends 791 this 
byte. The IOCB 200, now expecting to receive data, will provide the clock to 
the Slave, but reads each clocked data line pulse 829 for 1 or 0, capturing 8- 
bits per byte. 

[1*0 Address] [size] [sequenced #] [Command] [body] [EXT] [CRC-16] 
[8] [ 7 ] [79] [ACK] [0 bytes] [EXT] [OxCCCC] 

In this read mode, the Master must assert the ACK pulse 831 after each 
8-bits 827 to tell the Slave that the Master has received this byte. When the 
Master has received a number of bytes equal to "size" 823, it does not assert 
the ACK pulse and generates the stop condition 833 signifying the transfer 
has completed. The IOCB 200 receiving an ACK Command 825 to the polling 
Query, states the device is active but has no information to send. 
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As the IOCB 200 is the only Master on th'e r; i 2 G r bus 250, tfie^lQCB 200 
detects 771 the clockline asserted by any other device attempting to control 
the bus 250 during the polling process. After a small time-our : 835 ih the 
event there is a possible spike or glitch on the bus; the IOCB 20t) : fetests and, 
if this condition still exists, the IOCB 200 asserts the block line lbw#39 * 
disrupting and prevents any further I 2 C communications on thebfts^SO.' The 
IOCB 200 also reports this condition 841 to the SBC ifof error reporting; 
After the shut down, the IOC6 200 periodically releases the Clock* line 843 
. and re tests 845 for the above violation. If a retest shbWs tlife clofeVlihe is 
clear 847, the IOCB 200 broadcast tb r aH l 2 C * 

devices 3 listed in the device table, requiring each to reset "aiid s fer^gister. 
The IOCB 200 also reports 851 the cleared condition to the SBC 1. ' 

Due to the inherent security built in the preferred I 2 C protocol, and the 
internal security checks designed into the IOCB 200 and SBC 1, as described 
above, it, is virtually impossible for an alien device to invade the bus, or for a 
device to attempt communications with another device without the TOCB's 
knowledge and subsequent intervention. 

It will be appreciated by persons skilled in the 1 art that numerous 
variations and/or modifications may be made to the invention as shown in 
the specific embodiments without departing from the spirit or scope of the 
invention as broadly described. The present embodiments are, therefore, to 
be considered in all respects as illustrative and hot restrictive. 



;: 3JVO 99/jS19 r 94 



22 



PCT/AU99/00389 



CLAIMS: : ., vf , 

.1. . , A secured, inter-processor and virtual device digital communications 
system comprising: 

, lr a single board digital .storage and central processing unit means; 

, communication port connection means to the single board digital 
storage ,and ( . centra! processing unit means; 

a bidirectional connection means between the single board digital 
,stp,rage 1 and,central 1 p ) rocessing unit means and the input/output connection 
board; , u u< > r - • ■ 

.communication port connection means to the input/output coiinection 

board; ( 
a multi-drop capable communications protocol; 

a Plug-N-Play communications protocol; 

a mid ti-drop bidirectional communications-protocol capable 
connection means between the Input/Output Controller Board and 
connectable devices; 

at least one connectable device; and 

a central processing means for each connectable device. 

2. The secured inter-processor and virtual device communications system 
of claim I, wherein the single board digital storage and central processing 
unit means is comprised of an industry standard main Central Processing 
Unit . , 

3. The secured inter-processor and virtual device communications system 
as, claimed in claim 1 or 2, wherein the communication port connection 
means to the single board digital storage and central processing unit means is 
comprised of a parallel port. 

4. The secured inter-processor and virtual device communications system 
as claimed in any one of claims 1, 2 or 3, wherein the bidirectional 
connection means between the single board digital storage and central 
processing unit means and the input/output connection board is comprised of 
an ISA bus, 

5. The secured inter-processor. and virtual device communications system 
of claim 4, wherein the ISA bus is a PC-104 bus. 

6. The secured inter-processor and virtual device communications system 
as claimed in any one of claims 1, 2 or 3, wherein the bidirectional 
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... connection means between the single board digital storage and central u - 
processing unit means and the inpuVoutput cbnnecUon bbardis' comprised of 
an8-bitbus. 

7. , : The secured inter-processor and virtual device cbmmuhTcations system 
5 as claimed in any one of claims 1 to 6, wherein the cbinminicatioii port 

connection means to the input/output connection Hoard kre comprised of two 
8-bit parallel ports. ^ ^ " < v** ■. . o 

8. The secured inter-processor and virtual device- doftoiiriications : system 
of claim 7, wherein the two 8-bit parallel ports are comprised of a slave 

10 means for data and control, and a means to transmit ah B-Bi^tegister. 

9. The secured inter-processor and virtual device Communications system 
of claim 8, wherein ,the 8-bit register, comprises: 

a bit indicating whether the Input/Output Controller Board is ready to 
receive data; 

15 a bit indicating whether the Input/Output Controller Board has aborted * 

the reception of data sent by the main central processing unit; L ' - :,t 

a bit indicating whether the Input/Output Controller Board is^ready to 
send data to the main central processing unit; 

a bit indicating whether the lnput/Output Controller Board has aborted 
20 the sending of data to the main central processing Unit; 

. a bit indicating whether the Input/Output Controller Board 1 is busy 
processing a critical application; ' w 

a bit indicating whether the handshaking bits of the system should be 
ignored; and. 

25. , , a bit indicating that the Input/Output Controller Board has been ' : 
powered up or reset. "'■ " J 

10. The secured inter-processor and virtual device communications system 
as claimed in any one of claims 1 to 9, ; wherein the' mtilti-drdp capable 
communications protocol is comprised of a network-capable communications 

30 . protocol. m ' * ' 

11. The secured inter-processor and virtual device communications' system 
of claim. 10, wherein the multi-drop capable communications protocol is 
comprised of Philips' I 2 C communications protocdl. 

12. The secured inter-processor and virtual device communications system 
35 of claim 10, wherein the multi-drop capable communications protocol is 

comprised of anRS-485 communications protocol. 
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r 13. . The secured inter-processor and virtual device communications system 
of claim .10, /vyherein the multi-drop capable communications protocol is 
comprised of an USBcommunicatibns protocol. r 
1-1..,., .The^se^uredjnter-processor and virtual device communications system 
of claim 10, wherein the multi-drop capable communications protocol is 

.comprised, of a current loop communications protocol. 

15. t The secured inter-processor and virtual device communications system 
as claimed hi any one of claims i to 14, wherein' the Plug-N-Play 
communications protocol is comprised of: ~ - 

a device registering means; i , 

a communications routing means; ' ^ 

a communications arbitrating means; and : 7 ^ : 
a data transfer means. 

16. The secured inter-processor and virtual device communications system 
of claim 15, wherein the Plug-N-Play communications protocol is further 
comprised of: 

a device polling means; and 

a communications security means. 

17. The secured inter-processor and virtual device communications system 
of claim ,15 or 16, wherein the device registering means is comprised of: 

a means of determining the need for registering a device; 
a means. of assigning a default communication protocol address to a 
device; 

ajneans of allocating bus time "to register the device; 
a means of assigning a communication protocol address to a device; 
a means of obtaining information about a device; 
a means of assigning a virtual address to the device; 
a means of updating device parameters stored in a digital device table; 
a means of transmitting the registration information to the digital 
storage and central processing unit; 

a means of checking if the device is already registered; 

a means of acknowledging the validity of the device registration; 

a means of configuring the device; 

a means of adding the registered device to the polling list; and 
a means of deleting from the registered device to the polling list. 
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18. . The secured inter-propessor and yiVtiial device^coi^^cattons system 
of claim 15 16 or 17, the communications routing meahS is comprised^: 

a means for acknowledging a physical connection; ^ " - ' 

a means for communicating with' the main digit 

processing unit means; . T . ; ^ o , 

a means for assigning a 7 data packet with a specific pfdtoc:6l ; addre^s; 
a means for assigning a derta packet with a unique wttiar address; • 
a means for finding communications protocol 'addresse'sr , ^ 
a means for finding virtual addresses; 
a means for finding device information; 

a means for wrappings data packet with' a conimumcktibns protocol 

address; s . . 

, , ;a means for. wrapping a.data packet with information on the apparatus- 

initiating the, communication; . , 1 . . ; 

a means for wrapping a data packet with other information; 
a means for unwrapping communications protocol address and 
information from a data packet; 

^ . a means for transferring data packets initiated by the single board 
digital storage and central processing unit; and 

a means for transferring data packets initiated by' the devices. 
19. ... The. secured inter-processor and virtual device communications system 
of claim 17, wherein the means for updating device parameters stored in a 
digital device table is comprised of: 

a means for adding new device addresses and information; 
means for deleting device addresses and information; arid 
a means for modifying device addresses and information. 
; 20. The secured inter-processor and virtual device communications system 
of claims 17 or ; 19, wherein the means for updating d'e^ce information stored 
in a digital device table is comprised of a means to add, delete, and modify 
the following information for each connected device: 
a communications protocol address; 
a device type; ., 
a device make or model; . ... 
a device central processing unit serial number; 
a last reported device status; 
a device polling priority; and 
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: : -a devieetvirtualaddress. ■ 

21. The secured inter-processor and virtual device communications system 
of claim 18, the means of finding communications protocol addresses and 
finding device information is comprised of a means to locate virtual 
addressesHiv a digital devipe table. 

22. The secured inter-processor and virtual device communications system of 
claim 18 or 19, wherein the means of finding virtual addresses and finding 
device- information is comprised of a means, to locate communications 
protocol addresses in a digital device table. 

23. The secured inter-processor and virtual device communications system 
of claim 18,21 or-22, wherein the gleans of wrapping a data packet with a 
communications protocol address and the means of wrapping a data packet 
with other information are comprised of a means of creating the data packet 
of claim 31 wherein the body of the wrapped data packet includes the entire 
unwrapped data packet of claim 32. 

24. The secured inter-processor and virtual device communications system 
of claim 18, 21, 22 or 23, wherein the means of unwrapping communications 
protocol address and information from a data packet is comprised of a means 
of extracting the body of the wrapped data packet from the communications 
protocol wrapped data packet. ... > . 

25. The secured inter-processor and virtual device communications system 
of claim 18, 21, 22, 23 or 24, wherein the transferring of data packets initiated 
by the single. board digital storage and central processing unit is comprised of 
the steps of: i . 

a means for sending the unwrapped data packet to a Input/Output 
Controller Board; , . 

a means for retrieving the communications protocol address of the 
receiving device; ; 

a means for directing the unwrapped data packet to the input/output 
controller board for transmission to the addressed device; 

a 1 means for determining the validity of the received wrapped data 
packet; - , ^ 

; a means for reading the unwrapped data packet; 
- . a means for acting upon the instructions in the unwrapped data packet; 
and • ~> ■. ; . • 

. ameans for sending a confirmatory data packet to the sending device. 
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26. The secured inter-processor and virtual de vice ^communications system 
of claim 18, 21, 22, 23 or 24, wherein the riieans.ortrarfsferring of data , . 
packets initiated by devices is comprised' of : ,f -- ? tT .-.?:r:: ->r* ,-c.:;-ir.' n 

'a means for detecting an action of a device; = .;ob/f)h L 

a means for sending the wrapped data packet *toia i Input/Qutput v, 
Controller Board; ' " ' " kJ r "- jr ; T 

a means for sending a confirmatory data packet to the. sending: device; 

a means for determining 1 the validity of the received .unwrapped data 
packet; '" ; " : -'■ ^ s,v lw ?" *» " 

* Vmeans for reading the unwrapped data- packet; : ..a-nd>s?. en f . „ ; 

a meaiis for actiilg upon the instruGtidrisah the unwrapped data packet. 

27. ' The sfetai^d'mte^ device communications system 
of cfeim 15\ 21 i' 22; 23, 24,' 25 or 26, -wherein the communications. arbitrating 
means is comprised of: 

a means for providing a clock pulse; * ■ 

a means for enabling devices' to sample the data line to ensure the 
"intended level; J L * ; ' ' > . l . ■ 

a means for enabling devices to assert data onto the data* line at the 
intended level; : * ' v. r „ r .. j:v , ■• •.*..• 

a means for enabling devices to reset the protocol commitment;. and 

a meeuris for enabling devices to wait to assert data onto the data line 
until receipt of a signal. - < : : . v. *..■: . T ; ... < 

28: The secured iriter-processor and virtual device communications system 
as claimed in any one of claims 17 or 19 to 27, wherein the means of polling 
devices for status is comprised of: >*~ - ~- - j 

a means for providing the clock; "..-■;.*. , . 

a means for ensuring that the clock is provided by only one source; 

a means for indicating a poll to all devices; v. ? ^ , ; 

a means for preparing to receive data from devices; ? : v.,:?.; 

a means for indicating receive status; ' 1 , . J 

a means for indicating a unique'device address to be polled; 

a means for creating a data packet containing the poll query; . 

a means for sending a data packet containing the poll query; 

a means for devices to prepare to receive a polling. data: packet; 

a means for determining whether the poll is directed to a device; 

a means for determining tha^ the device should respond to the poll; 
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a means for creating a responding data packet with device information 
to the poll; 

a means for transferring a responding data packet to the poll; 
a means for determining the type of response to the poll; 
" a means' for "determining the validity of the response data packet; 
a means for updating device parameters stored in a digital, device table; ; 

and ^ f " 

a means for acknowledging the success of the poll 5 

29. The secured inter-processor and virtual device communications system 
as claimed mVny'onB^f 1 claims 16 to 24, wherein the communications 
security means is comprised or: . . 

a means for coiiiparing the size of the data packet received /with the 
size of the data packet sent; ; ' J i -■ " 

a means for comparing an expected sequential identification number of 
the packet received with the sequential identification number of the data 
packet sent; 

a means for comparing the end of the data packet sent with a code 
identifying the location of the end of the data packet sent; 

a means for creating and comparing a unique identification number of 
the data packet sent with a code identifying the unique identification number 
of the data packet sent: : - 

a means for sending a confirmatory data packet to the sending device. 

30. The secured inter-processor and virtual device communications system 
of claim 29^ wherein the means of comparing the size of the data packet 
received with the size of the data packet sent is comprised of a means of 
counting the size of the data packet received with a code identifying the size 
of the data packet sent. 

31. The secured inter-processor and virtual device communications system 
of claim 29 or 30, wherein the means 6f comparing an expected sequential 
identification number of the packet received with the sequential 
identification' number of the data packet sent is comprised of comparing dual 
and matching sequential counters for the sending device and the receiving 
device. ^ 1 

32. The secured inter-processor and virtual device communications system 
of claim 29, 30 or 31, wherein the means for comparing the end of the data 
packet sent with a code identifying the location of the end of the data packet. 
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sent is comprised of locating the end of the data packet sent and comparing 
the location with a code contained, in the data packet identifying the location 
of the end of the data packet received. .. ;r , ..^.j. .,. ; ; , , 

33. The secured inter-processor and virtual device .communications system 
of claim 29, 30, 31 : or 32, :r wherein.the means for creating and comparing a 
unique identification number of the data packet sent with a code in the data 
packet sent identifying the unique identification number of the data packet 
sent is comprised of a cyclic redundancy check algorithm. 

34. . The secured inter-processor and virtual device communications system 
of claim 33, wherein the cyclic redundancy qhe^ algorism of a 
16-bit;revers,e, polynomial-based algorithm performed . on,each byte sent and 
on each byte received in a data packet.. , , , , s . ; 

.35 The secured inter-processor and virtual device communications system 
of claims 25, .26 0^29,, wherein the means, for sending a confirmatory data 
packet to the sending device is comprised of: 
. a means for creating^ confirmatory data packet; 

a means for -sending the confirmatory unwrapped data packet to the 
Input/Output Controller Board; ; . . , : , 

; „; : a means for wrapping.the. confirmatory data packet with framing 
characters to create a wrapped data packet; 

, a.means for sending the confirmatory data packet to the sender; 
... a means for receiving the confirmatory data packet; ^ 
a means for stripping the wrapped confirmatory data packet; and 
a means for reading the unwrapped confirmatory data packet. 

36. . The secured inter-processor and virtual device cpminunications system 
in any one of claims 15 to 35, wherein the data transfer .means : is comprised 

of:, ... . — . , . * w:-; v-'V' ' 

v a communications prqtocol addressed wrapped data packet; and 
a virtual deviqe addressed unwrapped data packet. , _ 

37. The secured inter-processor and virtual device communications system 
of claim 36, wherein the communications protocol addressed wrapped data 
packet is comprised of a data packet with the following values: 

• a communications protocol address;, , . .. w; r- 
, 1 a size of the wrapped, data packet; ,r \,. 

^ a next sequence number for.the wrapped data packet; ^ . 
a type of sender of the data packet; 
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, a entire .unwrapped data packet; 
a last position of the wrapped data packet; and 
-, a unique 16-bit number for the wrapped data packet. 

38. • The secured . inter-processor and virtual device communications system 
l0 f claim '.36 i or ,37, wherein the virtual device addressed unwrapped data 

packet is comprised of a data packet with the following values: 
. . ,, .an. assigned. virtual address; , 
, ., a size, of the unwrapped data packet; 

a next sequence number for the unwrapped data placket; 

a type offender of the unwrapped data packet; 

a.deyice r .command embodied in the unwrapped data packet; 

a means of identifying the last position of the'uiiwifkpped data'packet; 
and .. ,. 

a unique 16-bit number for the unwrapped data packet. 

39. . The secured . inter-processor and virtual device communications system 
as claimed in claim 37 or 38, wherein the communications protocol address 
is comprised of an I 2 C address. 

40. The.secured inter-processor and virtual device communications system 
of claims 37, 38 or 39, wherein the unique 16-bit number is a number created 
by a cyclic redundancy check algorithm. 

41. The secured inter-processor and virtual device communications system 
as claimed in any one of claims 1 to 40, wherein the multi-drop bidirectional 
communications-protocol capable connection means is comprised of: 

. a clocking means; 
a data transfer means; 
a system grounding means; and 
a logic power means. 

42 . The secured, inter-processor and virtual device communications system 
of claim 41, wherein the clocking means is comprised of a wire contained in 
a bus connecting the Input/Output Controller Board with each device. 

43. The secured' inter-processor and virtual device communications system 
of claim 41 or 42, wherein, the data transfer means is comprised of a'wire 
contained in a bus connecting the Input/Output Controller Board with each 
device. 

44. The secured inter-processor and virtual device communications system 
of claim 41, 42 or 43, wherein the system grounding means is comprised of a 
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wire contained in a bus connecting the Input/Output Controllef 'Board with 
each device. '* * r ' ' ' / " ••.^■■t-*- 

. „, 45. The secured inter-processor and virtual devicfe cbinmumc'ations system 
of claim 41, 42, 43 or 44, wherein the logic power ^ea ; ris r is cbmprised' of a 
5 wire contained in a bus connecting the InpuVOutpu^ Controller Board with 
each device. . -^ -.^v. -oj . ^; ,tx. 

46. The secured inter-processpr and virtual'device communications system 
of claim 41, wherein the multi-drop communicate 
bidirectional connection means is comprised of an ft btis. ?/ ; ' 
10 47. ...The. secured inter-processor and virtual 'deviEe'c^hixntiMca system 
. ^ as claimed in any one'of claims 1 to 40, wherein tti£ coriri^ctabie device is a 
gaming machine device. ^ 

48. The secured inter-processor and virtual device communications system 
. ; , as claimed in, any one of claims 1 to 47, wherein the central processing 

15 u , *,means for each cpnnectable device is connected to at least one device. 

49. A method of creating a secured inter-processor arid virtual device 
: digital communications system comprising the steps of: ^ 

- ; { digitally and centrally storing and processing digital information' in a 
single board digital storage and central processing means; 
20 bidirectionally connecting the single board digital storage and central 

processing unit means and the input/output connecti6n board; 

; digitally storing and processing digital information in an input/output 
connection board; ' " - • , , . . , t . 

bidirectionally connecting at least one device to the input/output 
25 connection board in a multi-drop communications-protbcol ! capable 
configuration; ' fc - 

• . , havinga multi-drop capable communications protocol;* 1 
. providing a Plug-N-Play communications protocol; 
providing at least one connectable device; arid 
30 . providing a central processing means for each connectable device. 

50. , The method of creating a secured inter-prbcessorWd virtual device 
communications system of claim 49, wherein the step of bidirefitiohally 
connecting the single board digital storage and central' processing unit means 
and the input/output connection board further comprises the step of 

35 . providing.anlSAbus, ' 
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51. The method of creating a secured inter-processor and virtual device 
communications system of claim 50, wherein the step of providing an ISA 
bus further comprises the step of providing a PC-104 bus. 

52. / The .method of creating a secured inter-processor and virtual device 

5 communications system as claimed in claim 49, 50 or 51, wherein the step of 
1 bidirectional^ connecting the single board digital storage and central 
. processing unit means and the input/output connection board further 
.comprises providing an 8-bit bus. , . 

53. - T^me&odiOf .creating a secured inter-processor and virtual device 
10 communications system as claimed in claim 49, 50, 5 1 or 52, wherein the 

step of bidirectionally connecting at least one cjevice to the input/output 
connection board in a multi-drop configuration further comprises the step of 
providing an 8-bit register. * t . r ^., 

54. The method of creating a secured inter-processor and virtual device 
15 communications system of claim 5 3, wherein the step of providing an 8-bit 

register further comprises: 

indicating whether the Input/Output Controller Board is ready to 
receive data; 

indicating whether the Input/Output Controller Board has aborted the 
20 reception of data sent by the main central processing unit; 

indicating whether the Input/Output Controller Board is ready to send 
data to the main central processing unit; 

indicating whether the Input/Output Controller Board has aborted the 
sending of data to the main central processing unit; 
25 > indicating whether the Input/Output Controller Board is busy 
processing a critical application; 

whether the handshaking bits of the system should be ignored; and 

indicating whether the Input/Output Controller Board has been 
powered up or reset. 
30 55. The method of creating a secured inter-processor and virtual device 
communications system as claimed in any one of claims 49 to 54, wherein 
the step of bidirectionally connecting at least one device to the input/output 
connection board in a multi-drop configuration further comprises the steps 
of: 

35 providing a clocking means; 

transferring data; t 
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the system; and - ' i: ' ' J ' r- u.^:jc^/ 

powering the system! liJ J ' - ,J ij : J : " : ;■- — xjvk - 
56. . The method of creating 1 a secured intef-prbcessdr.arid virtual' de.vice 
communications system as claimed in any one' of claims' 49= to 54, wherein 
5 the step of having a multi-drop capable communications protocol further 
comprises the step of having a network-capable commuiiieations pTdtoGol. 
5 7. The method of cheating a' secured inter-pirocessbr *and? virtual device 
communications system of claim 56, wherein the step'of'having^avnetwork- 
capable communications protocol further corapnses'-tfiS^fepdMiaving a 
10 " Philips'l^ communications protocol.^ : : * ■' ~* ^:^r? ^oii^in,r : ;-. 

58. The method of creating' a secured ihtei^prbceissor and' virtual device 
communications system as claimed iri any one of claims '49>to -57, wherein 
the. step of providing a Plug-N-Play communications protocol further > 

. comprises the steps of: : ' 

15 registering devices; ' r : k 

routing communications; ! - ' } 

arbitrating'commuhications; and 

transferring data. . ; ; ■ * • 

59. The method of creating a secured inter-processor arid virtual device 
20 communications' system of claim 58; wherein the step of providing a Plug-N- 

Play communications protocol further comprises the steps of: 

polling devices for status; and ' ' i V - - 

providing a communications security means. ; ■ - ~ ; - 

60. The method of creating a secured intef-processor and virtual device 
25 communications system as claimed in claim 58 or 59, wherein the step of 

registering devices further comprises the steps of: ; ; - 
"determining thfe need for registering a device; 

assigning a default communication protocol address to a device; 

allocating bus time to register the device; 
30 assigning a communication protocol address to a device; >. 

obtaining information about a device; - . . , /r" 

assigning a virtual 5 address to the device;* ' 4 v rv-v- : 

updating device parameters stored ma digital device table; ' 

transmitting the registration information to the digital storage and 
35 central processing unit; L 1 ■■'^"7 

checking if the device is already registered; *; ■ / : 
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acknowledging the validity of the device registration; 
configuring the device; 

adding the registered device to the polling list; and 
deleting from the registered device to the polling list. ■ 

61. The method of creating a secured inter-processor arid virtual device 
communications system as claimed in claim 58; 59 or 60, wherein the step of 
routing communications further comprises the steps of: j ' 

acknowledging a physical connection; ^ 

communicating with the main digital storage and central processing 
unit means; • , >. . . \ . . 

assigning a : dafe packet with a specific protocol address; 
assigning a data packet with a unique virtual addf6ss> - - 
finding communications protocol addresses; ' * 2 --- v: ; * 
. a pieans for finding virtual addresses; ' > 
finding device information; 1 '"' 

wrapping a data packet with a communications protocol address;' 
wrapping a data packet with information on the apparatus initiating 
the communication; 

wrapping a data packet with other information; 

unwrapping communications protocol address and information from a 
data packet; 

transferring data packets initiated by the main digital storage and 
central processing unit; and 

transferring data packets initiated by the devices. - 

62. The secured inter-processor and virtual device communications system 
as claimed in claim 60 or 61, wherein the step of updating device parameters 
stored in a digital device table further comprises the steps of: 

adding new device addresses and information;' 
device addresses and information; and * 
modifying device addresses and information. 

63. The method of creating a secured" inter-processor and virtual device 
communications system as claimed in claims 60, 61 or 62, wherein the step 
of updating device parameters stored in a digital device table further 
comprises the steps of adding, deleting, and modifying the following 
information for each connected device: 

a communications protocol address; 
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a device type; 
a device make or model; r , r t v , ^ 

a device central processing unit serial number; ^ .^i,,.. 
a last reported. device status; % t 
i, a device polling priority; and . ; ? ; ^ ; . 

a device virtual address,. . ^ .. . _ ^- 

64. The method of creating a secured inter-processor and .virtual device 
communications system, of claim 61,, wherein the step.of _.finding 
communications protocol addresses and finding device information further 
comprises the step of locating virtual addresses, in a. digital t device table. 

65. The method'pf cr^ating.a secured jntej-processpr and virtual device 
communications system of claim 61, wherein the step of finding virtual 
addresses and finding device information further comprises the step of 
locating communications protocol addresses in a digital device table. 

66. ... -The , method of creating a secured inter-processor and virtual device 
communications system of claim. 66, wherein the step of wrapping a data 
packet with a communications protocol address and the/step bf wrapping a 
data packet with other information further comprises the step of creating the 
data packet of claim 80 wherein the body of the wrapped data packet 
includes the entire unwrapped data packet of claim 81. . 

67; < The method of creating a secured inter-processor and virtual device 
communications system of claim 61, wherein the step of unwrapping 
communications protocol address and information from a data packet further 
comprises the step : of extracting the body of the wrapped data packet from 
the communications protocol wrapped data packet. . 
68. The method of creating a secured inter-processor and virtual device 
communications system of claim 61, wherein the step of transferring of data 
packets initiated by the main digital storage and central processing unit 
further comprises the steps of: , . . t 

sending the unwrapped data packet to ; a Input/Output Controller 

Board; ; . , ■ 

(retrieving the communications protocol address of the receiving 

device; . • 

directing the unwrapped data packet to the input/output controller 

board for transmission to the addressed device; 

determining the validity of the received wrapped data packet; 
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reading the unwrapped data packet; 

acting upon the instructions in the unwrapped data packet; ; and 
sending a confirmatory data packet to the sending device. 

69. The method of creating a secured inter-processor and virtual device 
communications system of claim 61, wherein the step of transferring of data 
packets initiated by devices further comprises the steps of; 

, detecting an action of a device; 

*" sending tie' wrapped data packet to a Input/Output Controller Board; 
sending a confirmatory packet; 

determining the validity of the received unwrapped data packet; 
fearing the unwrapped data packet; and re- 
acting upon the instructions in the unwrapped data packet? * , 

70. The method of creating a secured inter-processor and virtual device 
communications system as claimed in any one of claims 58 to 69, wherein 
the step of arbitrating communications further comprises the steps of: 

providing a clock pulse; 

enabling devices to sample the data line to ensure the intended level; 
enabling devices to assert data onto the data line at the intended level; 
enabling devices to reset the protocol commitment; ahd 
enabling devices to wait to assert data onto the data line until receipt 
of a signal. 

71. The method of creating a secured inter-processor and virtual device 
communications system as claimed in any one of claims 59 to 70* wherein 
the step of polling devices for status further comprises the steps of: -» • 

providing the clock; 

ensuring that the clock is provided by only one source; 

indicating a poll to all devices; 

preparing to receive data from devices; 

indicating receive status; * , 

indicating a unique device address to be polled; 

creating a data packet containing the poll query; 

sending a data packet containing the poll query; 

devices preparing to receive a polling data packet; 

determining whether the poll is directed to a device; 

determining that the device should respond to the poll; 

creating a responding data packet with device information to the poll; 
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a means of transferring a responding data packet to me poll;^ 
determining the type of response to the poll; _ * \ 
determining the validity of the response date packet^ ^ 
updating device, parameters stored in a digital ( deyice bipie^and 
acknowledging the ; success of the poll - v es " wr . )t . ... . 

72. The method of creating a secured inter-processor* and ' virtual ^evice 
communications system as claimed in any one of claims 59' to 71, wherein 
the step of providing a communications security means ^ tothe^pomprises the 
steps of: , L - . , , 

comparing the size of the data packet received .with .Jhe size ot the data 

packet sent; ... -^v,-. A ■ n : r . v : ■ r , r " • ; . r . 

comparing an-expected sequential identification number of the packet 
received with the sequential identification number of the data packet sent; 

: comparing the end of the data packet sent with a' code identifying the 
location of the end of the data packet sent; 

creating and T comparing a unique identification number of the data 
packet sent with a code identifying the unique identification number of the 
data packet sent; and 

sending a confirmatory data packet to the sending device. 

73. The method of creating a secured inter-processor and virtual device 
communications system of claim 72, wherein the step of comparing the size 
, of the data packet received with the size of the data packet sent further 
comprises the step of counting the size of the data packet received with a 
code identifying the size of the data packet sent. 

74. The method of creating a secured inter-processqr and virtual device 
communications system as claimed in claim 72 or 73, wherein the step of 
comparing an expected sequential identification number' of the packet 
received with the sequential identification number of the data packet sent 
further comprises the step of comparing dual and matching sequential 
counters for the sending device. and the receiving device. 

75. The method of creating a secured inter-processor and virtual device 
communications system as claimed in claim 72 v 73 or 74, wherein the step of 
comparing the end of the data packet sent with a code identifying the 
location of the end.of ,the data packet sent further comprises the steps of 
locating the end of the, data packet sent and comparing the location with a 
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code contained in the data packet identifying the location of the end of the 
data packet received. 

76. The method of creating a secured inter-processor and virtual device 
communications system as claimed in claim 72, 74 or 75, wherein the step of 
creating and comparing a unique identification number of the data packet 
sent with a code in the data packet sent identifying the unique identification 
number of the data packet sent further comprises the^step of performing a 
cyclic redundancy check algorithm. 

77, ... Tije method of creating a secured inter-processor and virtual device 
communications system of claim 76, wherein the step of performing a cyclic 
redundancy check algorithm further comprises the step of performing a 16- 
bit reverse polynomial-based algorithm on each byte sfcnt and on each byte 
received in a data packet ' ' c 

78. The method of creating a secured inter-processor and virtual device 
communications system as claimed in any one of claims 68 or 69, wherein 
the step of sending a confirmatory data packet to the sending device further 
comprises the steps of: 

creating a confirmatory data packet; 

sending the confirmatory unwrapped data packet to the Inpul/Gutput 
Controller Board; 

. , wrapping the confirmatory data packet with framing characters to 
create a wrapped data packet; 

sending the confirmatory data packet to the sender; 
. receiving the confirmatory data packet; 
. stripping the wrapped confirmatory data packet; and 
. reading the unwrapped confirmatory data packet. 

79. The method of creating a secured inter-processor and virtual device 
communications system as claimed in any one of claims 58 to 78, wherein 
the step of transferring data further comprises the steps of: 

providing a communications protocol addressed wrapped data packet; 

and 

; providing a virtual device addressed unwrapped data packet 

80. The method of creating a secured inter-processor arid virtual device 
communications system of claim 79, wherein the step of providing a 
communications protocol addressed wrapped data packet further comprises 
the step of creating a data packet with the following values: 
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a communications protocol address; 
..... a size of the wrapped data packet . 7 ' 

a next sequence number for the wrapped data packet 1 ;' ; 

a type of sender of the data packet; 

5 ... an entire unwrapped data packet; ; , l _ r ^ 

: a last position of the wrapped data packet; and - ' 1 " " j " J w aI :iJ 
a unique 16-bit number for the wrapped data packet ' u ' ' ' J *' " 
81, The method of creating a secured ihter-processbr arid visual device 
communications system as claimed in claim 79 or '&&; wherein tfre step of 
10 providing a virtual addressed unwrapped data packet 4 further comprises 1 the 
.step of creating a data packet with the following values: * *• " 

an assigned virtual address; 
. - f4 -- a size of the unwrapped data packet; 
i? .^a next sequence number for the unwrapped data packet; 
15 .... /...a, type of sender of the unwrapped data packet; 

a device command embodied in the unwrapped data packet; 
a means for identifying the last position of the unwrapped' data packet; 
, and • 

a unique 16-bit number for the unwrapped data packet 
20 82.. The method of creating a secured inter-processor and virtual device 
communications system as claimed in claim 80 or 81, wherein the step of 
creating a communications protocol address further comprises the step of 
providing an I 2 C address. 

83. The method of creating a secured inter-processor and virtual device 

25 communications system as claimed in claim 80/ 81 or 82, Mierein the step of 
creating a unique 16-bit number for the data packet further' Comprises the 
. step of applying a cyclic redundancy check algorithrii. 

84. The method of creating a secured inter-processor and virtual Idevice 
communications system of claim 55 , wherein the step of providing a clocking 

30 means further comprises the step of including a wire in a bus connecting the * 
Input/Output Controller Board with each device. 

.85. The method of creating a secured inter-processor and' virtual device 
communications system of claim 55 or 84, wherein the 'step'of transferring 
data further comprises the, step of including a wire in "a bus^cbrinecting the 
35 Input/Output Controller Board with each device. * 
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86. r The method of creating a secured mter-processor and virtual device 
communications system of claim 55, 84 of 85, wherein the step of grounding 
the system further comprises the step of including a wire in a bus connecting 
the Input/Qutjmt Controller Board with each device. 

87. The method of creating a secured inter-processor arid virtual device 
communication^ system of claim 55, 84, 85 or 86, wherein the step of 
powering the system further comprises the step of providing a wire in a bus 
cpnnecting .the Jnjput/Output Controller Board with each device. 

88. The method of creating a secured inter-processor and virtual device 
coiimiunicatio^ system as claimed in any one of claims 49 to 87, wheriein 
the step of bidirectionally connecting at least one device to the input/output 
connection board in a multidrop connection further comprises the step of 
containing the clocking means, the data transfer means, "the system ground 
means, and the logic power means in the multi-drop connection. 

89. The method of creating a secured inter-processor and virtual device 
communications system as claimed in any one of claims 49 to 88, wherein 
the step of providing at least one connectable device further comprises the 
, step of providing gaming machine devices. 

90. The method of creating a secured inter-processor and virtual device 
communications system as claimed in any one of claims 49 to 89, wherein 
the step of providing a central processing means for each connectable device 
further comprises the step of connecting each central processing means to at 
least one device. 

91. A Plug-N-Play communications protocol for devices comprising: 
a device registering means; 

a communications routing means; 
. a communications arbitrating means; and 
a data transfer means. 

92. The Plug-N-Play communications. protocol of claim 91, wherein the 
Plug-N-Play communications protocol is further comprised of: 

a device polling means; and 

a communications security means. 

93. The Plug-N-Play communications protocol of claim 91 or 92, wherein 
the device. registering means is comprised of: 

a means of determining the need for registering a device; 
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a means of assigning a default communication protocol address to a 
device; • 

a means of allocating bus time to register the 'device! * ' ,; * ■■ k - 4 - 
. a means of assigning a communication pro tocbr address t6 a' device; 

a means of obtaining information about a device;" 

a means of assigning a virtual address to the device;'* v> f 

a means of updating device parameters stored in a^digital device table; 
; a means, of transmitting the registration infbrniatidn to ; the' digital 
storage and central processing unit; . '[ " " 

a means of checking if the device is ak^ 

a means of acknowledging the validity of the device registration; 

a means of configuring the device; " 

a means of adding .the registered device to the polling list'; and ]' 

a means of deleting from the registered device to the polling list. 
94. The Plug-N-Play communications protocol of claim 91, 92 or 93, : 
wherein the communications routing means is comprised of : 

a means for acknowledging a physical connection; 

a means for communicating with the main digital storage and central 
processing unit means; 

a means for assigning a data packet with a specific protocol address;^ 

a means for assigning a data packet with a unique virtual address; 

a means for finding communications protocol 1 addresses; 

a means for finding virtual addresses; 

a means for finding device information; 

a means for wrapping a data packet with a communications protocol 
address; ' * 

a means for wrapping a data packet with informatibh'bn the apparatus 
initiating the communication; * " 

a means for wrapping a data packet with other information; 

a means for unwrapping communications protocol address and 
information from a data packet; 

a means for transferring data packets initiated by the main digital 
storage and central processing unit; and 

a means for transferring data packets initiated by the devices. 



u^P 99/61994 



PCT/AU99/00389 



42 

95. The Plug-N-Play communications protocol of claini 93 or 94, wherein 
the means for updating, device parameters stored in a digital device table is 

comprised of: ;. . , 

; . , ' a means for adding new device addresses and information; 

a means for deleting device addresses and information; and 
.- , i , !( a means, fpr modifying device addresses and information. 

96. The Plug-N-Play communications protocol of claims 93, 94 or 95, 
wherekvthe ,me?ms for updating device parameters stored in a digital device 
table is compiised.pt ^mean^ to add, delete, and modify the following 
information^ - t .. 

a communications protocol address; 

a device type; . . ^ . 

a device make or model; 

a device central processing unit serial number; 
a last reported device status; r . 
a. device polling priority; and ^ 
, a device virtual address. 

97. The Plug-N-Play communications protocol of claim 94, wherein the 
means of finding protocol addresses and finding device information is 
comprised of a means to locate virtual addresses in a digital device table. 

98. . The Plug-N-Play communications protocol of claim 94, wherein the 
means of finding virtual addresses and finding device information is 
comprised of a means to locate communications protocol addresses in a 
digital device table. ^ , 

99. The Plug-N-Play communications protocol of claim 94, wherein the 
means of wrapping a data packet with a communications protocol address 
and the means. of wrapping a data packet with other information are 
comprised of a means for creating the data packet, wherein the body of the 
wrapped data packet includes the entire unwrapped data packet. 

100. The Plug-N-Play communications protocol of claim 94, wherein the 
means of unwrapping communications protocol address and information 
from a data packet is comprised of a means of extracting the body of the 
wrapped data packet from the communications protocol wrapped data 
packet. , 
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101. The Plug-N-Play communications protocol of claim 94; wherein the*' 
transferring of data packets initiated by the mam HigitaL storage and central 
processing unit is comprised of the steps of: - ' - : ; - 

a means for sending the unwrapped data patket-to ariVKput/Output 
Controller Board; , ' . * ' \ -cv^wi. 

a means for retrieving the dommunications protScohaddtess-bf the 
receiving device; ' ' 1 ' ' c * A " l ' J "-- Ci - i x 1 

a means for directing the unwrapped data pacfe 
controller board for transmission t6 the addressed rfevide7 l i' '^" 

a means for determining the Validity of ttife^ ; 
packet; ''' z "**" ^ r ^' rr/ " ■"' 7l -<-' r -' ' 

a means for reading the unwrapped data packet;* 1 

a means for acting upon the instructions in the unwrapped data packet; 
and ' " K 

a means for sending a confirmatory data packet to the sending device. 

102. The Plug-N-Play communications protocol of claim 94/ wherein the 
means of transferring of data packets initiated by devices is comprised of: 

a means for detecting an action of a device; 
. r - a means for sending the wrapped data packet to an Input/Output ' l 
Controller Board;. . * " ^ ; 

a means for sending a confirmatory data packet to the sending device; 

a means for determining the validity of the received unwrapped data 
packet; , ■.-.*.„* ... > 

a means for reading the unwrapped data packet; and x - : - - * 

a means for acting upon the instructions in the unwrapped data packet.-" 

103. The Plug-N-Play communications protocol as claimed in any one of 
claims 91 to 102, wherein the communications arbitrating 1 means is ; 
comprised of: , 1 - 

a means for providing a clock pulse; ~ ' f ] 
a means for enabling devices to sample the data line to ensure the 
intended level; 

a means for enabling devices to assert date onto the data line atthe 
intended level; : : - ^ r 

a means for enabling devices to reset the protocol commitment; and 
a means for enabling devices to wait to assert data onto the data line 
until receipt of a signal. 
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104. The Plug-N-Play communications protocol.of claim 92, wherein the 
means of 'polling devices for status is comprised of: . : 
a means for providing the clock; , . , ; - 
• a means' for' ensuring that the clock is provided by only one source; 
- a means for indicating a poll to all devices; 
" "••a-meajw'foi>preparing to iB.eeive.da.ta from devices; 
a means for" indicating receive status; , . 
1 a meahs- for indicating a unique device address to be polled; 
- " a means for creating a data packet containing the poll, query; . 
; * ' ••aL-mea&^fof^eJiding a -.data packet containing the poll query; 

a means for devices to prepare to receive a.pplling data packet; } 
ETmeans for determining whether the poll is directed to a , device; 
a means for determining that the device should respond to the poll; 
a means for creating a responding data packet with device information 
to the poll; ; 

a means for transferring a responding data packet to the poll; 

a means for determining the type of response to the poll; 

a means for determining the validity of the response data packet; 

a means for updating device parameters stored in a digital device table; 

and 

a means for acknowledging the success of the poll. . 
105. The Plug-N-Play communications protocol of claim 92 or 104, wherein 
the communications security means is comprised of: 

a means for comparing the size of the data packet received with the 

size of the data packet sent; 

a means for comparing an. expected sequential identification number of 
the packet received, with the sequential identification number of the data 
packet sent; 

■ ■ < a means for comparing the. end of the data packet sent with a code 
identifying the location of the end of the data packet sent; 

a meansfor creating and comparing a unique identification number of 
the data packet sent with a code identifying the unique identification number 

of the data packet sent; and 

a means for sending a confirmatory data packet to the sending device. 
106. The Plug-N-Play communications protocol of claim 105, wherein the 
mearis of comparing the size of the data packet received with the size of the ' 
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data packet seiit is'cbmprised of a means'bfc'ounti-iig/th&size^the- data, 
packet received with a code identifying the sizeof the data : packetsent. . .. , 

107. The Plug-N-Play communications protocol of claim ,105 oi>106, 
wherein the means of comparing an expected sequenMalidentification 
number of the packet received with the sequential identification, number of 
the data packet sent is comprised of comparing dual ^a^dcmatching.sequential 
counters for the sending device and the receiving device;/: ^-orr- 

108. The Plug-N-Play*cbmmunicatioris protocol of claim ;10,5^ 016 : or 107, 
wherein the means for comparing the end of the data fpackej sent with a code 
identifying the* location of the end of the data packet^ent : iis ; c ; qinprised of 
locating the end of the data packet sent and; comparing -the location with a 
code cohtainecl in the data'packet identifying the location of the^end of the 
data packet received." ; ' ' ; - tf ■ r \ v-'-y.t* 

109. The Plug-N-Play communications protocol of claim 105, 106, 107 or 
108, wherein the means for creating and comparing unique identification 
number of the data packet sent with a code in the data packet sent 
identifying the unique identification number of the data packet sent is 
comprised of a cyclic redundancy check algorithm. 

110. The Plug-N-Play communications protocol of claim 109, wherein the 
cyclic redundancy check algorithm is comprised of a 16-bit reverse r . 
polynomial-based algorithm performed on , each byte sent and on each byte 
received in a data packet. 1 : -. . ; 

111. The Plug-N-Play communications protocol of claim 101, wherein the 
means for sending a confirmatory data packet to the sending device is 
comprised of: - ; 

a means fbr creating a confirmatory data packet;, ( . 

a means for sending the -confirmatory unwrapped data packet to the 
Input/Output Controller Board; ? 

a means for wrapping the confirmatory data packet with framing 
characters to create a wrapped data packet;. * ■ , - r -, ■ ( ,- 7 

a means for sending the confirmatory data packet to the sender; 
* a mean's for receiving the confirmatory data packet; ' , ; ; ; 

a means for stripping the wrapped confirmatory data packet; and 

a means for reading the unwrapped confirmatory data packet. 

112. The Plug-N-Play communications protocol as claimed in any one of .. 
claims 91 to 111, wherein the data 1 transfer means is comprised of: . 
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, , a pommiinications protocol addressed wrapped data packet; and 
a yirtual ( device addressed unwrapped data packet. 

113. The Plug-N-Play communications protocol of claim 112, wherein the 
communications protocol addressed wrapped data packet is comprised of a 
data packet with the following values: 

f . a i O a : communications protocol address; 
.. y v \ £ size of the .wrapped data packet; 

a next sequence number for the wrapped data packet; 

a type of sender of the data packet; . 
, : a^entire unmapped data packet; 

a last position of the wrapped data packet; and . ( 

a unique . 16-bit number for the wrapped data packet. . 

114. The Plug-N-Play communications protocol of claim 113,' wherein the 
virtual device addressed unwrapped. data packet is comprised of a data 
packet with the following values: 

an assigned virtual address; 
a size of the unwrapped data packet; 
a next sequence number for the unwrapped data packet; 
a type of sender of the unwrapped data packet; 
a device command embodied in the unwrapped data packet; 
a means of identifying the last position of the unwrapped data packet; 
and , t . ■ t 

J( ; v a ( unique 16-bit number for the unwrapped data packet. 

115. The Plug-N-Play communications protocol of claim 113 or 114, 
wherein the communications protocol address is comprised of an I 2 C address. 

116. The Plug-N-Play communications protocol of claims 113, 114 or 115, 
wherein the unique 16-bit number is a number created by a cyclic 
redundancy check algorithm. 

117. A methpd of creating a Plug-N-Play communications protocol for 
devices comprising the steps. of: 

registering devices; 
routing communications; 
arbitrating communications; and 
transferring data. . 
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118. The method of creating a ^iug-N-Play 'comihiinic for 
devices of claim 117, wherein 'the method of c^eating-a Plug^Play 
communications' protocol further comprises the'stepS* of : ; ' ; - ; - 

polling devices for status; and 0 w™*^**^ 1 ■' 

providing a communications security means. 3i * ' :Lt ' '** : ■-' * ::: 

119. The method of creating a Pliig-N-Play communications protocol for 
devices of claim 117 or 118, wherein the ; step of registering devices further 
comprises the steps of: ' * ' * ' ~ '" J J ' J ' x ' h 

determining the need for registering a device;"'" — 
assigning a default communication- prbtocol i^a^drb'As ta'a^evice; 
allocating bus time to register the device; , r ~ v : '' 11 - 4 
assigning a communication protocol address to a device; - 
' f obtaining ^ inWmation about a devicer " ; - 

assigning a virtual address to the device; - 1 1 • 

updating device parameters stored in a digital device table;' J - 
transmitting the registration information to the digital storage and 
central processing unit; 

checking if the device is already registered; 
acknowledging the validity of the device registration; 
configuring the device; " ' - 

the registered device to thfe polling list; and " : >: !! " " 

deleting from the registered device to the polling list. 

120. The method of creating a Plug-N-Play communications protocol for 
devices of claim 117, 118 of 119, wherein the step of routing communications 
further comprises the steps of: 1 *' ' "** 

acknowledging" a physical connection; : :S " 

communicating with the main digital storage and central processing 

unit means; 1 

assigning a data packet with a specific protocol address; ^ 
assigning a data packet with a unique virtual addrbss; - ' J 1 
finding communications protocol addresses; e ' r: ■ - r : : 
finding virtual addresses; i.*w . ,. u- v 

finding device information; ' v ' ^ 

wrapping a data packet with a communications protocol Address; 
wrapping a data packet with information on the apparatus initiating 

the communication; 
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1 - wrappinga data packet with other information; 

unwrapping communications protocol address and information from a 
data packet;, 

transierring : data packets initiated by the main digital storage' and 
central .processing unit; and 
1 . -^transferring datapackets initiated by the devices. 

121. The method of creating a Plug-N-Play communications protocol for 
devices of -claims 149 or 120, wherein the step of updating device parameters 
stored in^lsi}aL : deyice it table further comprises the steps of: 

:, adding: new device .addresses and information; 
deleting device addresses, ^nd information; and. 
modifying device addresses and information. 

122. The method of creating a Plug-N-Play communications protocol for 
devices of claims 119, 120 or 121, wherein the step of updating device 
parameters stored in a digital device table further comprises the steps of 
adding, deleting, and modifying the following information for each 
connected device: 

a communications protocol address; 
a device type; 
a device make or model; 
a device central proce3sing unit serial number; 
a last reported device status; 
- a device polling priority; and . _ 

. . a device virtual address. 

123. The method of creating a Plug-N-Play communications protocol for 
devices of claim 120, 121 or 122, wherein the step of finding communications 
protocol addresses and finding device information further comprises the step 
of locating virtual addresses in a digital device table. 

124. The method of creating a Plug-N-Play communications protocol for 
devices of claim 120, 121, 122 or 123, wherein the step of finding virtual 
addresses . and finding device information further comprises the step of 
locating communications, protocol addresses in a digital device table. 

125. - The method of creating a Plug-N-Play communications protocol for 
devices of claim 120, 121, 122, 123 or 124, wherein the step of wrapping a 
data packet with a communications protocol address and the step of 

■• wrapping a data packet with other information further comprises the step of 
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creating the data packet of 'claim' 139 ^ data 
packet includes the entire unwrapped data pacJMof daifr : 141\- " n ♦ 

126. The method of creating a Plug-N-Play commiuiications protocol for . 
devices as claimed in any one of claims 120 to 125', -wfiSiieMit&S step of 

5 unwrapping communications protocol address 1 and irifbrffi'ilion»'frpm"a data 
packet further comprises the step 1 of extracting -the body of the Wrapped data 
packet from the communications' protocol wrapped data r -pa*c'ket. $r-;y . i 1 ; 

127. The method of creating a Plug-N-Play communications' pi?dtdcol: for - 
devices as claimed in any one of "clainis 120 to 126; : wherbiiilthe^tep of 

10 transferring of data packets initiated b^the main^ central 
processing unit further comprises "the steps of:* 4 * " '' r ' r ""- ' ;V f « f} --' 

sending the unwrapped data packet to ^input/Output' Controller 

Board; , : * " ' 

retrieving ;"'thle communications protocol address of the ! receiving 

15 device;, 

directing the unwrapped data packet to the input/output controller 
board for transmission to the addressed device; * - : ? 

determining the validity of the received wrapped data- packet; 
reading the unwrapped data packet; f 
20 acting upon the instructions in the unwrapped data packet; and 

sending a confirmatory data packet to &e sending device^ - 

128. The method of creating a Plug-N-Play communications protocol for 
devices as claimed in any one of claims 120 to 127, wherein^the 1 step of 
transferring of data packets initiated by devices further comprises the steps 

detecting an action of a device; ""' - • - ' ' ' : r " 

sending the wrapped data packet to a Input/Output Controller Board; 
sending a confirmatorypacket; - Xi u/ ~ 

determining' the validity of the received* unwrapped data packet; 
30 reading the unwrapped data packet; and ~ > r- 

acting upon the "instructions in the unwrapped date packet. s ■)'•■ 

129. The method overeating a Plug-N-Play cbmmunicatidris protocol for 
devices as claimed in any one of claims 11 7 'to 128, wherein the^step of * 
arbitrating communications 'further comprises the steps ofP'* : ~' ? 

35 .. providing a clock' pulse; "*■ '' ' ' J ' U x: : "• v " 

enabling devices to sample the d : ata line to ensure r the intefided level; 
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enabling devices to assert data onto the data line at the intended level; 
enabling devices to reset the protocol commitment; and 
enabling devices' to wait to assert data onto the data line until receipt 
of a signal. o v , _ 

130. The metho.d of creating a Plug-N-Play communications protocol for 
devices as claimed in any one of claims li9 to'128, wherein the step of 
polling devices for 

. , providing the clock; 

ensuring that the clock is provided by only one source; 

. indicating.a poll to all devices; ' : ! 

preparing to receive data from devices; ■ ■ ■ j ■ ■ 
indicating receive status; i - 

indicating a unique device address to be pdlled'; ' ' J 
creating a data packet containing the poll query; 
sending a data packet containing the poll query; 
devices preparing to receive a polling data packet; ~ 
determining whether the poll is directed to a device; 
determining that the device should respond to the poll; 
creating a responding data packet with device information to the poll; 
a means of transferring a responding data packet to the poll- 
determining the type of response to the poll; 
determining the validity of the response data packet; 
updating device parameters stored in a digital device table; and 
acknowledging the success of the poll 

131. The method of creating a Plug-N-Play communications protocol for 
devices as claimed in any one of claims 119 to 128 or claim 130, wherein the 
step of providing a communications security means further comprises the 
steps of: 

comparing the size of the data packet received with the size of the data 
packet sent;. 

comparing an expected sequential identification number of the packet 
received with the sequential identification number of the data packet sent; 

comparing the end of the data packet sent with a code identifying the 
location of the end of the data packet sent; 
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creating and comparing a unique identification iiumWrb^ the data 
, packet sent with a code identifying the unique identification* riumber of the 
data packet sent; and 

■ sending a confirmatory data packet to the sending device. * ' 
5 132. The method of creating a Plug-N-Play communications' protocol fbr 
devices of claim 131, whereia the step of comparing the size of the 'data " 
packet received with the size of the data packet sent ; furthei 'comprises 1 the 
step of counting the size of the data packet received with a 1 code identifying 
the size of the data packet sent. .. . , 

10 133. The method of creating a Plug-N-Play communications protocol tor 
devices of claim 131 or 132, wherein the step of comparing an expected 
sequential identification number of the packet received with' the sequential , : 
identification number of the data packet sent further comprises Hie step of 
comparing dual and matching sequential counters for the sending device and^ 

15 the receiving device. 

134. The method of creating a Plug-N-Play communications protocol for 
devices of claim 131, 132 or. 133, wherein the step of comparing the end of 
the, data packet sent with a code identifying the location of the end of the 
data packet sentiurther comprises the steps of locating the end of the data 

20 packet sent and comparing the location with a code contained in the data 
packet identifying the location of the end of the data. packet received. 

135. The method of creating a Plug : N-Play communications protocol for 
devices of claim 131, 132, 133 or 134, wherein the step of creating and 
comparing a unique identification number of the data packet sent with a 

25 . code in the data packet sent identifying the unique identification number of 
the data packet sent further comprises the step of performing a cyclic 
redundancy check algorithm. 
; 136/ The method of creating a Plug-N-Play communications protocol for 
devices of claim 135, wherein the step of performing a cyclic redundancy 
30 <■ check algorithm further, comprises the step of performing a 16-bit reverse 

polynomial-based algorithm on each byte sent and on each Byte received in a 
- data packet. 

137, The method of creating a Plug-N-Play communications protocol for 
devices of claim 131 , wherein the step of sending a confirmatory data packet 
35 to the sending device further comprises the steps of; 
creating a confirmatory data packet; 
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sending the confirmatory unwrapped data packet to the Input/Output 
Controller Boani; . - > 

wrapping the confirmatory data packet with framing characters to 
create a wrapped data packet; 

sending the confirmatory data packet to the sender; 

receiving 'the confirmatory data packet; 

stripping the wrapped confirmatory d&ta packet; and 

reading the unwrapped confirmatory data packet * * 

138. The method of creating a Plug-N-Play communications protocol for 
devices as claimed in any one of claims 117 to 137, wherein the step of 
transferring data further comprises the steps of: 

providing a communications protocol addressed wrapped data packet; 

and 

providing a virtual device addressed unwrapped data packet. 

139. The method of creating a secured inter-processor and virtual device 
communications system of claim 138, wherein the step of providing a 
communications protocol addressed wrapped data packet further comprises 
the step of creating a data packet with the following values: 

a communications protocol address; 

a size of the wrapped data packet; 

a next sequence number for the wrapped data packet; 

a type of sender of the data packet; 

an entire unwrapped data packet; 

a last position of the wrapped data packet and 

a unique 16-bit number for the wrapped data packet. 

140. The method of creating a Plug-N-Play communications protocol for 
devices of claim 139, wherein the step of creating a communications protocol 
address further comprises the step of providing an f C address. 

141. The method of creating a Plug-N-Play communications protocol for 
devices of claim 138, 139 or 140, wherein the step of providing a virtual 
addressed unwrapped data packet further comprises the step of creating a 
data packet with the following values: 

an assigned virtual address; 

a size of the unwrapped data packet; 

a next sequence number for the unwrapped data packet; 

a type of sender of the unwrapped data packet; 
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a device command embodied in the unwrapped data packet; , 
; . 1 means for,identifying the last position of thq unwrapped data packet; 

a unique 16-bit number for the unwrapped data jacket. , 
142. The method of creating a Plug-N-Play communic^tioiii? protocol for 
devices of claims 139 and .140 or. 141, wherein the step of creating a unique 
16-bit number for the,data packet further comprises the step of applying a 
cyclic -redundancy check -algorithm.. r . )( . h ..: J ",... 
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